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PREFACE 


The  research  documented  in  this  technical  report  for  the  Virtual  Space 
Logistics  Readiness  Center  (VSLRC)  program  sponsored  by  the  Air  Force 
Research  Laboratory,  Human  Effectiveness  Directorate,  Sustainrrient  Logistics 
Branch  (AFRL/HESS),  Wright-Patterson  Air  Force  Base,  OH.  Synergy,  Inc. 
performed  the  work  under  Delivery  Order  #21  of  the  Technology  for  Readiness 
and  Sustainment  (TRS)  contract  F33615-99-D-6001.  Lt.  Randy  P.  Allen 
(AFRL/HESS)  was  the  program  manager  for  the  effort. 
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1  Purpose 

The  purpose  of  this  Technical  Report  -  Concept  of  Operations  (CONOPs)  is  to  collect,  analyze  and  define 
high-level  needs  and  features  of  the  Virtual  Space  Logistics  Readiness  Center  (VSLRC).  It  focuses  on 
the  capabilities  needed  by  the  stakeholders  and  targeted  users,  and  why  those  needs  exist.  The  specific 
details  of  how  the  VSLRC  fulfils  those  needs  are  described  in  the  use  case  and  software  requirements 
specifications. 

1.1  System  Overview 

The  VSLRC  is  an  interactive  system  that  increases  support  to  the  space  systems  warfighter  by  providing 
access  to  near  real-time  system  operational  and  equipment  status,  and  linking  logistics  data  to  its  impact 
on  operational  readiness.  The  VSLRC  will  integrate  all  necessary  logistics,  maintenance,  and  operations 
data  into  a  single  system  that  decision-makers  can  use  to  identify,  diagnose,  and  take  corrective  actions  to 
solve  logistics  issues  in  the  space  systems’  supply  chains. 

The  VSLRC  description  contained  in  this  document  is  based  upon  initial  research  conducted  by  the  Space 
and  Missile  System  Center/Detachment  1 1  AP  (SMC/Det  1 1)  and  findings  described  in  a  VSLRC  concept 
paper.  The  Air  Force  Research  Laboratory  (AFRL)  and  Synergy,  Inc.  gathered  additional  information 
through  interviews  with  various  Headquarters  Air  Force  Space  Command,  Space  and  Missile  System 
Center/Detachment  1 1  (HQ  AFSPC,  SMC/Det  11),  and  Ogden-Air  Logistic  Center  (00-ALC) 
organizations. 

1.1.1  General  Nature  of  System 

VSLRC  is  a  web-based  system,  and  will  operate  within  a  portal-like  environment  that  adheres  to  Air 
Force  and  Department  of  Defense  (DoD)  interoperability  standards.  Initially,  the  VSLRC  will  be  housed 
in  a  secure  environment  (i.e..  Secure  Internet  Protocol  Network  (SIPRNET)),  but  will  eventually  transfer 
information  between  classified  and  unclassified  environments  for  ease  of  use. 

1.1.2  Development  Background 

VSLRC  development  is  broken  into  four  phases: 

•  Phase  1  -  SMC  Det  1 1/AP  develops  a  limited  capability  web  site  that  pulls  together  available 
and  relevant  operations  and  logistics  information  about  space  systems 

•  Phase  2  -  The  AFRL  funds  VSLRC  requirements  and  technology  feasibility  study  conducted 
by  Synergy,  Inc.  that  includes  a  Return  On  Investment  (ROI)  analysis  and  a  concept 
demonstration 
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•  Phase  3  -  Additional  Top  Ten  Supply  Drivers  methodologies  for  all  space  programs  and 
provide  development  on  an  Interactive  Concept  Demonstration 

•  Phase  4  -  Depending  on  the  outcome  of  Phase  2,  iterative  spiral  development  for  the  VSLRC 
begins 

These  CONOPs  is  developed  as  part  of  Phase  2  of  this  effort.  To  collect  this  information  as  well  as  a  set 
of  initial  software  requirements  and  use  cases,  Synergy  Inc.  participated  in  interviews  and  data  collection 
sessions  with  SMC  Det  1 1/AP,  Headquarters  Air  Force  Space  Command/LZ  (HQ  AFSPC/LZ),  System 
Sustainment  Managers  (SSMs),  00-ALC/LHJ,  14"'  AF/A4  and  Aerospace  Operations  Center  (AOC),  50"' 
Space  Wing,  and  the  21*'  Space  Wing. 

1.13  Identification  of  Key  Participants 

Several  organizations  are  involved  in  the  development  of  the  VSLRC.  Key  participants  include: 

•  Project  Champion:  SMC  Det  1 1/AP 

•  Project  Sponsor:  AFRL  (Technology  and  Feasibility  Study) 

•  Users:  Everyone  inyolved  in  the  space  systems  supply  chain  to  include  but  not 

be  limited  to  the  following: 

-  HQ  AFSPC 
- 14  AF 

-  SMC  Det  1 1 

-  Electronic  System  Center  (ESC)  Det  5 

-  00-ALC/LH 

-  Others 

•  Developers:  Synergy,  Inc.  and  the  University  of  Dayton  Research  Institute  (UDRI) 

•  Support  Agencies:  None 

1.1.4  Current  and  Planned  Operating  Sites 

Although  users  of  the  VSLRC  are  widely  geographically  dispersed,  the  initial  operating  site  will  be  at  the 
Centralized  Integration  Support  Facility  (CISF),  Peterson  AFB. 

1.1.5  Assumptions  and  Constraints 

Each  of  these  factors  affects  the  requirements  stated  in  the  CONOPs,  use  case,  and  software  requirements 
specifications.  These  factors  are  not  design  constraints  on  the  software,  but  any  changes  to  them  can 
affect  requirements. 
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•  Continued  access  to  required  data  systems  and  data 

•  Continued  access  to  subject  matter  experts  and  user  representatives 

1.2  Document  Overview 

This  document  depicts  the  various  user  and  stakeholder  requirements  and  a  concept  for  how  the  VSLRC 
will  meet  those  needs.  Various  other  data  sources  and  systems  are  also  reported  in  order  to  best 
understand  the  existence  of  similar,  disparate  systems,  interface  requirements,  the  utilization  of  various 
tools,  and  the  need  for  consolidation  of  some  systems  and  requirements. 

2  Problem  Statement 

2.1  Description  of  the  Problem 

The  Air  Force  Space  community  currently  has  no  near  real-time,  secure,  web-enabled  means  for  data 
exchange  and  display.  Visibility  and  status  of  space  system  assets  is  critical  for  accurate  decision-making 
and  reporting,  but  the  current  method  of  obtaining  this  information  is  manually  intensive  and  disjointed. 
Organizations  must  often  access  several  disparate  information  systems  or  hardcopy  reports  to  determine 
the  status  of  space  systems,  and  often  time’s  data  collection  is  duplicated  across  the  supply  chain.  In 
addition,  not  everyone  has  access  to  the  information  needed,  or  the  information  they  do  have  is  suspect, 
out  of  date,  and/or  inconsistent  with  what  others  are  seeing.  Not  only  is  it  difficult  for  SSMs  and  others  to 
determine  the  overall  long-term  health  of  space  systems,  but  those  focused  on  solving  day-to-day  logistics 
and  sustainment  problems  issues  are  often  forced  to  be  reactive  instead  of  proactive. 

2.2  Opportunity  for  New  System 

The  VSLRC  will  solve  these  problems  by  providing  three  primary  functions: 

•  Report  screens  that  display  operational,  equipment,  and  communications  equipment  status 
simultaneously  for  space  systems 

•  Informational/diagnostic  screens  that  integrate  data  from  multiple  Air  Force,  contractor,  and 
other  DoD  legacy  information  and  analytical  systems 

•  Automated  messaging  for  early  identification  of  potential  problems 

These  functions  provide  all  members  of  the  supply  chain  with  a  consistent  view  of  the  health  and  status  of 
space  systems,  in  addition  to  simultaneous  notification  of  problems  and  a  common  picture  of  the 
information  required  for  timely  resolution. 
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2  J  Existing  Systems 

Several  data  sources  and  tools  exist  today  that  will  contribute  to  the  VSLRC.  Some  systems  contain  data 
that  the  VSLRC  must  collect,  process,  analyze  and  report,  while  others  contain  functionality  that  may  be 
integrated  into  the  VSLRC.  Interface  linkages  may  also  exist  between  various  systems  and  the  VSLRC. 
These  are  described  below.  No  single  system  exists  today  that  provides  all  of  the  capabilities  required  by 
the  VSLRC. 


System-  Tools 

Name 

Description 

LOCIS 

Logistics  Control  and 
Information  Support 

The  Logistics  Control  and  Information  Support 
(LOCIS)  program  is  researching  and  developing 
information  technologies  to  enhance  the  ability  of 
the  logistics  community  to  effectively  manage 
logistics  resources  and  assimilate  logistics 
information  for  decision-making  in  an 

Expeditionary  Air  Force/Agile  Combat  Support 
Command  and  Control  environment. 

LASAR 

Logistics  Analysis 
Supportability 

Assessment  Resource 

Logistics  Analysis  Supportability  Assessment 
Resource  (LASAR)  focuses  the  weapon  system 
analysis  on  a  series  of  key  metrics  indicating  the 
weapon  system’s  overall  health  or  readiness. 

These  metrics  include  identifying  diminishing 
manufacture  sources,  mission  capability  rates, 
trends  and  limiting  components,  personnel 
limitations,  component  mean  time  between  failure, 
logistics/supply  chain  throughput  (both  Air  Force 
(AF)  and  Defense  Logistic  Agency  (DLA))  and 
critical  wartime  spares  analysis. 

PIN 

Parts  Information 

Network 

Parts  Information  Network  (PIN)  is  an  interactive 
system,  designed  to  assist  its  users  in  supporting 
the  E-3  aircraft  Programmed  Depot  Maintenance 
(PDM)  process  by  reducing  Awaiting  Parts  (AWP) 
time  for  DLA-managed  parts,  reducing  the  need 
for  Phased  Depot  Maintenance  (PDM)  delays, 
and  thereby  increasing  supportability  to  the 
warfighter. 

PSA 

Predictive  Support 
Awareness 

Predictive  Support  Awareness  (PSA)  will  provide 
a  comprehensive  link  between  sustainment 
planning  and  operations.  PSA,  through  source 
sustainment  analysis,  will  provide  decision-makers 
with  the  ability  to  predict  shortages  and  determine 
resource  alternatives  to  avoid  logistics  barriers. 

D087P 

Pipeline  Performance 
Analysis  System  (PPAS) 

The  Weapons  System  Management  Information 
Systems  (WSMIS/PPAS)  modernization 
environment  includes  I)  Pipeline  analysis  for  the 
following:  base  repair,  retrograde  repair,  Logistics 
Response  Time  (LRT),  contract  repair  and  depot 
repair.  2)  An  initiative  to  provide  visibility  into 
customer  wait  time  (CWT).  CWT  measures  the 
time  it  takes  from  order  to  receipt  when  customer 
requirements  are  satisfied,  from  wholesale  and 

Name 


LRT-AF 


Logistics  Response  Time 
-  Air  Force 


WSAP 


SENSORNET 


D087T 


Weapon  System 
Analysis  Program 


Sensor  Network 


TRACKER 


SBMCS  - 
Logbook, 


MCRS 


YARD 


Space  Battle 
Management  Core 
System 


Mission  Critical 
Reporting  System 


Variance  Analysis 
Reporting  Database 


Balanced  Scorecard 


Description _ 

retail  transactions  as  well  as  other  arrangements. 
This  capability  will  allow  Air  Force  logisticians  to 
identify  and  analyze  problems  in  the  CWT 
pipeline  in  order  to  make  decisions  based  on 
performance.  Specifically,  CWT  is  a  metric  that 
measures  the  total  elapsed  time  between  when  a 
customer's  documented  requirement  is  established 
and  when  that  customer  acknowledges  receipt  of 

the  material  requested. _ 

Logistics  Response  Time-Air  Force  (LRT-AF)  is 
wholesale  pipeline  activity  for  the  Air  Force.  It 
tracks  the  average  time  from  when  a  requisition  is 
submitted  (by  individual  requisition  and  by  unit) 
until  the  requisitioned  item  is  actually  received. 
There  are  four  logistics  response  time  segments 
(01-04):  01.  base  requisition  segment,  02.  ICP 
process  segment,  03.  DLA  process  segment  and 
04.  transit  segment. 


Weapon  System  Analysis  Program  (WSAP) 
organically  developed  and  maintained  system 
within  AFSPC/LGS  that  performs  metrics 

calculations  on  various  weapon  system  data. _ 

Sensor  Network  (SENSORNET)  is  a  nationwide 
real-time  detection,  identification,  and  assessment 
system  of  Chemical,  Biological,  Radiological,  and 
Nuclear  (CBRN)  threats.  _ 


TRACKER  provides  comprehensive  supply, 
transportation,  acquisition,  and  maintenance 
information  to  support  the  various  functions  of  the 
logistics  support  office,  with  the  primary  focus 
being  pipeline  performance  analysis  and 
transportation  billing  validation.  TRACKER’S  data 
warehouse  allows  individual  requisitions  / 
shipments  to  be  tracked  via  the  worldwide  web, 
with  emphasis  on  flightline,  base-level 
requirements.  TRACKER  provides  key  functional 
capabilities  into  the  consolidated  database  /  web 
enabled  WSMIS  /  decision  support  environment. 


Space  Battle  Management  Core  System  (SBMCS) 
combines  all  status  and  outage  information  for  the 
ground/control  and  space  segments.  Logbook  to 
be  incorporated  into  Mission  Critical  Reporting 
System  (MCRS) -Jul  03.  _ 


Mission  Critical  Reporting  System  (MCRS) 
displays  status  and  outage  information  for  all 
satellite  constellations. 


Variance  Analysis  Reporting  Database  (YARD) 

Air  Force  Material  Command  (AFMC)  Mission 
Impaired  Capability  Awaiting  Parts  (MICAP)  sent 
from  Tobyhanna  to  00-ALC  IMs  for  review  of 

SQRs  and  causes. _ 

Balanced  Scorecard  (BCS)  is  a  management 
system  which  integrates  an  organization’s  strategic 
operating  objectives  with  balanced  performance 
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DSS 

Decision  Support  System 

MERLIN 

Multi-Echelon 

Resource  and 

Logistics  Information 
Network 

ORA 

Operational  Readiness 
Analysis  System 

RAMES 

Reliability,  Availability 
and  Maintainability 
Engineering  System 

VICP 

Virtual  Networking 

System  (VINES)  Internet 
Control  Protocol  (VICP) 

WICAP  (DLA) 

Worldwide  Industrial 
Capabilities  Assessment 
Program 

SMART 

Systems  Metric  and 
Reporting  Tool 

Description _ 

measures  to  drive  achievement  of  the  strategy 
throughout  the  organization.  00-ALC/LHJ 
initiative  to  use  BSC  (Global  Positioning  Satellite 
(GPS)  Ground  Segment  as  pilot)  against  specified 
metrics  in  an  effort  to  normalize  the  potential 
framework. _ 

Decision  Support  System  (DSS)  is  a  web-based 
program  which  allows  users  to  assess  the 
sustainability  of  the  sensor  sites  by  helping  them 
monitor  important  system  metrics  and  make 
proactive  decisions  to  support  the  sites. 


Multi-Echelon  Resource  and  Logistics  Information 
Network  (MERLIN)  is  tool  used  to  generate  the 
System  Executive  Management  Report  (SEMR) 
via  SIPRNET. 

Tool  developed  at  00-ALC  to  identify 
performance  by  shop  Production  to  include 
induction,  constraints,  open  MICAPs,  MICAP 
hours,  MICAP  incidents,  MICAP  Hours 
comparison,  MICAP  incidents  comparison, 
weapon  system  comparisons,  backorders, 
requisitions,  etc.  Data  is  put  on  screen  in  web 
browser  in  bar  graph,  and  can  be  downloaded 
to  Excel,  or  ppt  presentation.  Data  sources 
include,  but  are  not  limited  to,  D165B, 

D087X,  D035K  and  D200. _ _ 

Reliability,  Availability  and  Maintainability 
Engineering  System  (RAMES)  identifies 
reliability  and  maintainability  trends  at  all  level, 
identifies  bad  actors,  supports  “what  if’  and 
“many  to  one  replacement”,  and  ROI  analyses,  and 
can  be  used  to  validate  Modernization  Planning 
Process  (MPP)/  Program  Objective  Memorandum 
(POM)  inputs  to  support  both  the  warfighter  and 
sustainment  communities. 


Virtual  Networking  System  (VINES)  Internet 
Control  Protocol  (VICP)  is  used  to  notify  errors 
and  changes  in  network  topology.  VICP  frames 
may  contain  parameters  on  Cost  and 

Communication  Error. _ 

Worldwide  Industrial  Capabilities  Assessment 
Program  (WICAP)  is  used  for  procurement, 
retooling,  etc.,  to  show  procurement  history  to 
decrease  lead-time  and  lower  prices  to  the 
Government. 


Systems  Metric  and  Reporting  Tool  (SMART)  is 
a  Program  Manager’s  Command  and  Control  Tool 
that  replaces  program  reporting  with  information 


System-  Tools 

Name 

Description 

access.  SMART  replaces  current  Defense 
Acquisition  Circular  (DAC),  Program  Executive 
Officer  (PEO),  and  Service  Acquisition  Executive 
(SAE)  program  reviews  with  access  to  current 
program  information. 

D002A 

Standard  Base  Supply 
System  (SBSS) 

The  Standard  Base  Supply  System  (SBSS)  is  a 
unified  management  system  that  provides 
inventory  control,  workload/material  management 
actions  and  accommodates  various  funds  control 
actions  for  all  base  (retail)  level 
supplies/equipment  for  automated  material 
management  and  system  users,  SBSS  operates 
through  the  collective  interactions  of  supply 
procedures,  service  procedures,  internal  and 
external  system  interfaces,  processing  routines, 
and  the  SBSS  computer  terminals. 

G054 

Core  Automated 
Maintenance  System 
(CAMS) 

Core  Automated  Maintenance  System  (CAM)  is 
the  Air  Force  standard,  production-oriented,  base- 
level  automated  maintenance  information 
management  system.  The  system  supports  all 
aircraft,  communications-electronics,  and  support 
equipment  maintenance  activities  at  93  worldwide 
main/host  operating  bases,  118  Air  National 
Guard/Air  Force  Reserve  sites,  and  selected  North 
Atlantic  Treaty  Organization  (NATO)  locations. 
CAMS  replaced  manual  maintenance  data 
collection  and  maintenance  work  order  systems  by 
providing  on-line  remote  terminals  connected  to 
the  Standard  Base-Level  Computer  (SBLC) 
system  throughout  the  maintenance  complexes. 
CAMS  automate  aircraft  history,  aircraft 
scheduling  and  aircrew  debriefing  processes  to 
provide  a  common  interface  for  entering  base- 
level  maintenance  data  into  other  standard 
logistics  management  systems. 

G099 

Reliability  and  . 
Maintainability 
Information  System 
(REMIS) 

Reliability  and  Maintainability  Information 

System  (REMIS)  will  receive  selected  weapons 
system  maintenance  information  in  detailed  and 
summary  format  from  the  Core  Automated 
Maintenance  System  (CAMS),  CAMS  for  airlift 
(G081),  Integrated  Maintenance  Data  System 
(IMDSX  and  depot  and  contractor  technology 
repair  centers  by  direct  on-line  input  and  file 
transfer  protocol  (FTP)  via  the  defense 
information  system  network.  Data  elements 
collected  and  reported  will  be  those  pertaining  to 
aerospace  vehicle,  trainer,  and  automated  test 
equipment  (ATE)  inventory,  status  and  utilization; 
maintenance  data  documentation  (MDD)  on  all 
reportable  types  of  equipment;  actual  and 
approved  configuration  data;  time  change  and 
inspection  data,  and  time  compliance  technical 
order  data.  Additionally,  REMIS  will  establish 
selected  on-line  edit  and  validation  tables  to  be 
maintained  by  designated  Air  Force  personnel  to 
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WARRS 

D035K 


Wholesale  and  Retail 
Receiving  and  Shipping 


Source  of  Repair 
Assignment  Process 


Requirements  Data  Bank 
(RDB) 


D087H  - 
REALM 


Enterprise  Data 
Warehouse 


Requirements/Execution 
Availability  Logistics 
Module 


Description 


ensure  data  accuracy.  Frequency  of  data 
transmission  will  be  in  accordance  with 
established  and  approved  interface  control 
documents  between  all  systems. 


Wholesale  and  Retail  Receiving  and  Shipping 
(WARRS)  is  a  legacy  mainframe  D035  subsystem 
that  provides  retail  customer  support  including  bit- 
and-piece  parts  and  end-item  support  to  depot 
maintenance.  Maintains  historical  data  for  all 
accountable  depot  retail  transactions  and  for  Air 
Force  receipts  into  the  depot  and  for  shipments  out 
of  the  depot. 


Source  of  Repair  Assignment  Process  (SORAP)  is 
the  primary  method  by  which  depot  maintenance 
posturing  decisions  for  both  hardware  and 
software  are  made.  It  applies  to  both  new 
acquisition  and  fielded  programs.  It  is  designed  to 
ensure  compliance  with  all  applicable  factors, 
including  public  law,  that  merit  consideration  in 
achieving  a  best  value  depot  maintenance  source 
of  repair.  For  new  acquisitions,  the  System 
Managers  (SMs)  should  initiate  the  SORAP  as 
soon  as  feasible  in  the  acquisition  process.  For 
fielded  systems,  a  SORAP  is  required  for  all 
workload  shifts,  modifications,  and  workloads 
proposed  to  be  accomplished  in  an  overseas  arena. 
The  Requirements  Data  Bank  (RDB)  system 
comprises  a  set  of  major  logistics  processes  and 
models  integrated  by  a  large  relational  database. 
RDB  automates  and  integrates  the  Air  Force 
materiel  requirements  determination  processes 
which  compute  procurement  and  repair 
requirements  for  spares,  repair  parts  and  major 
equipment  items.  RDB  uses  a  planning  period  of 
38  quarters  and  recomputed  quarterly.  The 
relational  database  is  the  repository  of  detailed 
information  showing  the  indentured  application  of 
every  individual  part  of  each  particular  aircraft 
type  or  end  item.  Within  this  structure  the  system 
holds  the  historical  and  planning  data  needed  to 
support  computation  of  quantities  for  buy  and 
repair.  The  data  includes:  past  and  projected 
weapon  system  operating  programs;  future 
readiness  goals;  maintenance  and  modification 
schedules;  item  failure  rates  and  condemnations. 
Data  query,  modeling  and  management  report 
generation  are  on-line. 


Enterprise  Data  Warehouse  (EDW)  stores  aircraft 
information  previously  located  on  several 
computer  systems.  Integrates  this  information, 
provides  enhanced  access,  and  analytical  query 
capabilities  to  produce  tailored  reports. 


D087H-Requirements/Execution  Availability 
Logistics  Module  (REALM)  computes  depth  of 
spares  requirements  for  Readiness  Spares 


System-  Tools 

Name 

Description 

Packages  (RSPs). 

Tobyhanna  MS 
Access  DB 

N/A 

Tobyhanna  creates  an  access  database  comprised 
of  AFMC  MICAPS,  which  they  then  send  to  OO- 
ALC/LH  for  further  analysis  and  reporting 
requirements. 

GIDEP 

Government/Industry 

Data  Exchange  Program 

Government/Industry  Data  Exchange  Program 
(GIDEP)  a  cooperative  effort  to  exchange 
research,  development,  design,  testing,  acquisition, 
and  logistics  information  among  Government  and 
industry  participants.  GIDEP  seeks  to  reduce  or 
eliminate  expenditures  of  time  and  money  and  to 
improve  the  total  quality  and  reliability  of  systems 
and  components  during  the  formulation  and 
implementation  processes  of  program  and  project 
management.  Informs  subscribers  when  a 
vanishing  vendor  decides  they  may  stop  producing 
an  asset. 

WSSP 

Weapon  System  Support 
Program 

The  DLA  Weapon  System  Support  Program 
(WSSP)  was  established  to  enable  the  services  to 
identify  to  DLA  those  common  consumable  parts 
required  to  ensure  adequate  supply  posture  in 
support  of  organizational  readiness  objectives.  It 
enhances  the  readiness  and  sustainability  of  the 
military  services  by  providing  the  maximum 
practical  level  of  support  for  DLA-managed  items 
with  weapon  system  application.  The  DLA  WSSP 
enables  DLA  to  develop  an  investment  strategy 
that  is  geared  to  the  criticality  of  the  weapon 
system  end  items  as  registered  in  the  WSSP  and 
the  essentiality  of  their  component  parts.  The 
information  provided  to  the  DLA  WSSP  drives 

DLA  support  for  weapon  systems.  DLA  uses  the 
WSSP  to  establish  funding  priorities,  make 
personnel  assignments,  initiate  procurement 
actions,  tailor  business  arrangements,  and  focus 
attention  on  national  stock  numbers  (NSNs) 
degrading  mission  capability  of  the  military 
services’  materiel  requirements. 

EDW 

Enterprise  Data 

Warehouse 

Enterprise  Data  Warehouse  (EDW)  stores  aircraft 
information  previously  located  on  several 
computer  systems.  Integrates  this  information, 
provides  enhanced  access,  and  analytical  query 
capabilities  to  produce  tailored  reports. 

Space  Ops 

Center  Portal 

N/A 

SMC  Det  1 1/AP  has  developed  a  limited 
capability  web  site  that  pulls  together  available 
and  relevant  ops  and  logistics  information  about 
space  systems. 

2.3.1  LOCIS  Evaluation  -  In  Work 

LOCIS  is  a  3-year  proof  of  concept  Advance  Technology  Demonstration  being  developed  by  AFRL/ 
HESR  and  officially  sponsored  by  the  Agile  Combat  Support  Division  in  the  Air  Force  Command  and 
Control  Intelligence,  Surveillance,  Reconnaissance  Center  (AFC2ISRC/LG).  The  LOCIS  program  is 
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researching  and  developing  information  technologies  to  enhance  the  ability  of  the  US  Air  Force  C2  and 
logistics  community  to  effectively  manage  resources  and  assimilate  information  to  support  decision¬ 
making  in  an  Expeditionary  Air  Force/Agile  Combat  Support  Command  and  Control  Environment. 

This  evaluation  is  based  on  the  review  of  Spiral  2  software  not  including  an  Entity  Relationship  Diagram 
(ERD)  and  a  Technical  Interchange  Meeting  (TIM)  on  Thursday,  29  May  2003  with  BAE  Systems,  the 
developers  of  Spiral  2  and  3  of  the  LOCIS  System.  Therefore,  representative  information  will  require  a 
more  thorough  analysis  and  is  only  based  on  information  presented  to  Synergy,  to  date.  Results  may 
change,  depending  upon  further  analysis  of  the  LOCIS  source  code,  software  application  and  receipt  of 
appropriate  documentation. 

The  following  stakeholder  requirements  were  presented  to  BAE  Systems: 

1 .  Visibility  of  operational,  equipment  and  comm.  Status 

2.  Visibility  of  logistics  and  maintenance  impact  on  operational  readiness 

3.  Collection  of  maintenance  and  logistics  data  that  support  metrics  calculation 

4.  Instant  notification  of  critical  logistics  problem 

5.  Visibility  of  item  status,  location,  and  disposition 

6.  Drill-down  from  equipment  status  to  underlying  causes 

7.  Integration  with  Balanced  Scorecard 

8^  Produce  MICAP  Reports  ~~ 

9.  Determine  overall  equipment  status  based  on  status  of  system  components 

10.  Identify  top  maintenance  and  supply  drivers 

1 1 .  Conduct  single  point  failure  (SPF)  analysis 


•  BAE  Systems  believes  that  the  LOCIS  current  design  would  be  able  to  support  all  but 
stakeholder  requirements  3,  7,  and  1 1 

•  Requirement  3  requires  that  the  database  hold  historical  data.  LOCIS  was  designed  only 
to  contain  current  data 


Requirement  7  deals  with  the  integration  with  Balanced  Scorecard.  BAE  was  unfamiliar 
with  this  system 


•  BAE  Systems  said  that  they  are  not  currently  providing  an  analysis  specific  to  Single 
Point  Failure  (SPF)  analysis;  however,  they  have  experience  in  doing  similar  analyses  (he 
believes)  and  BAE  Systems  could  incorporate  this  capability 

2.3.1.1  Front-end 

LOCIS  is  principally  a  system  consisting  of  an  applet  front-end  communicating  to  servlets  on  the  middle- 
tier,  which  in  turn  communicate  with  the  database.  According  to  BAE  Systems,  the  applet  (and  LOCIS 
framework)  may  provide  the  best  opportunity  for  applicability  and  reuse  in  the  implementation  of  VSLRC 
without  any  (or  much)  rework.  BAE  Systems  discussed  some  objects  used  in  the  applet  that  could 
probably  be  incorporated  in  the  VSLRC,  including  a  Grid  object  for  displaying  tables  and  providing 
primary  and  secondary  sorting  and  a  Scheduler  object  that  graphically  displayed  much  like  a  Gantt  chart. 
Further  discussions,  however,  indicated  that  the  front-end  is  still  tightly  coupled  with  the  middle-tier 
servlets.  An  example  of  this  is  the  Tail  ID  that  is  used  everywhere. 

Another  concern  is  that  the  VSLRC  requirements,  thus  far,  have  not  required  the  use  of  an  applet.  It  is 
believed  that  all  of  the  storyboard  screens  designed  thus  far  can  be  easily  developed  with  Java  Server 
Pages  (JSPs.) 

2.3.1.2  Middle-tier 

Servlets  are  fairly  well  geared  toward  supporting  the  front-end  applet,  rather  than  developed  in  a  more 
object  oriented  and  web-service  oriented  approach. 

2.3.1.3  Database 

The  database  is  primarily  designed  with  Aircraft  in  mind.  BAE  systems  investigated  and  developed  a 
more  maintenance/logistics  oriented  schema.  However,  this  schema  has  not  been  incorporated  as  the 
changes  would  likely  ripple  and  require  changes  to  middle-tier  and  front-end  components. 

There  may  be  some  opportunity  in  reuse  of  processes  being  used  to  obtain  data  from  other  systems. 

LOCIS  is  using  a  product  called  Info  Connect  to  do  some  ‘screen  scraping’  to  legacy  systems  like  CAMS 
and  G081 .  It  also  uses  a  sophisticated  tool  referred  to  as  the  Text  Based  Parser.  This  tool  would  take 
FTP  files  and,  based  on  a  properties  file,  would  parse  the  FTP  files  appropriately. 

BAE  Systems  discussed  the  investigation  of  Agent  technologies  for  their  source  data.  The  problem  lies 
with  the  fact  that  your  agents  need  to  communicate  with  agents  on  the  other  end  and  none  of  the  source 
systems  have  agents  with  which  to  communicate.  With  the  evolvement  of  EDW,  this  capability  to 
incorporate  this  technology,  message  oriented  adapters,  etc.,  may  be  possible. 


II 


2.3.1. 4  Architecture 

LOCIS  is  currently  built  upon  a  fairly  simple  web  application  architecture.  It  does  not  currently  use  alerts 
via  messaging  systems.  Alerts  are  currently  generated  by  polling  the  data  store.  BAE  Systems  would  like 
to  re-design  using  Oracle’s  triggers  to  generate  alerts.  They  also  indicated  that  they  would  like  to  explore 
the  use  of  JMS  or  other  to  better  implement  an  event  oriented  system  including  alerts. 

2.3.1 .5  Re-usable  Components 

This  area  will  be  further  examined  and  reported  in  VSLRC  Phase  II. 

2.3.1. 6  Web  Application 

Spiral  3  has  been  re-organized  into  the  more  standardized  Web  Application  directory  structure  and  now 
includes  a  web.xml  file.  This  was  largely  done  as  part  of  the  port  to  Web  Logic  Application  Server.  Still, 
the  LOCIS  does  not  take  advantage  of  an  application  servers  hooks  for  authentication  and  security 
protection.  The  authentication  is  currently  handled  within  the  applet.  The  system  currently  does  not  use 
connection  pooling  nor  does  it  get  its  data  source  from  Java  and  Naming  Directory  Interface  (JNDI). 

23.2  Possible  Integration  of  Predictive  Support  Awareness  (PSA)  with  VSLRC 

Synergy,  Inc.  was  asked  to  review  both  PSA  and  VSLRC  and  identify  potential  areas  for  system 
integration.  The  following  are  data  points  relative  to  the  possible  integration  of  both  PSA  and  VSRLC 
concepts: 

•  Enterprise-wide  reach  to  capture  and  disseminate  critical  information 

•  Visible  impact  to  logistics  operations/processes.  Command  and  Control  (C2)  functions  and 
requirements/metrics 

-  Marriage  of  operational  and  logistics  information 

•  Alerts  and  triggers 

-  Alerts  those  affected  when  changes  occur  within  AFMC  and  AFSPC  that  affect  asset 
status  and  require  analysis 

-  Assists  in  take  action  efforts 

-  Automatic  updates  to  senior  management  briefings 

•  Real-time  monitoring  of  inventories  and  parts  management 

-  Inventory  management  focused  on  providing  parts  to  keep  weapon  systems  and  space 
systems  fully  mission  capable 


12 


Focus  on  achieving  desired  operational  effects 


•  Statistical  Analysis 

-  Metrics 

-  Time  Trends  via  historical  data 

•  Stoplight  charting 

-  Red  -  Non-Mission  Capable  (NMC),  Amber  -  Partial  Mission  Capable  (PMC),  Green  - 
Fully  Mission  Capable  (FMC) 

-  Drill  down  detail  of  “bad  actors,”  driving  requirements  and  critical  constraints 

■  Map-based  interface  for  data  visualization 

■  Complements  the  AF  portal  environment 

•  Identification  of  other  ongoing  AFMC  and  AFSPC  scientific  technological  efforts 

PSA  is  currently  a  prototype  system  and  has  many  capabilities  and  potential  functionality.  While 
reviewing  the  key  stakeholder  and  user  needs  identified  in  Paragraph  3.3,  it  is  foreseen  that  the 
functionality  of  the  PSA  prototype  can  meet  all  but  the  following  requirements: 

•  Integration  with  Balanced  Scorecard 

•  Conduct  Single  Point  Failure  (SPF)  analysis 

•  Produce  Unit,  Wing,  and  NAF  SITREPs 

However,  these  requirements  can  be  integrated  with  further  iterations  of  development. 

3  Stakeholder  and  User  Descriptions 

3.1  Summary  of  Stakeholders  and  Users 

Air  Force  Space  Command  consists  of  a  headquarters  element  located  at  Peterson  AFB,  the  14*'’  Air  Force 
at  Vandenberg  AFB,  and  the  20"’  Air  Force  at  F.E.  Warren  AFB.  Wings  supporting  the  14"'  Air  Force  are 
responsible  for  operating  and  maintaining  all  space  systems  and  ground  segments,  while  the  20*''  is 
responsible  for  Intercontinental  Ballistic  Missiles  (ICBM).  The  Space  and  Missile  Systems  Center 
(SMC)  at  Los  Angeles  AFB  is  home  to  the  space  system  program  offiees,  and  is  responsible  for 
acquisition,  logistics,  and  sustainment.  SMC  Detachment  11,  located  at  Peterson  AFB,  is  responsible  for 
logistics  readiness,  infrastructure  support,  and  sustainment  of  space  systems,  and  is  home  to  the  space 
system  SSMs. 
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The  Supply  Chain  Manager  for  Space  Systems  is  located  at  the  Ogden  Air  Logistics  Center  (OO-ALC). 

the  Space  Systems  Support  Division  provides  wholesale  item  management,  production 
management,  and  sustainment  support  to  the  SSMs  and  System  Program  Directors  (SPDs)  for  space 
ground,  satellite,  and  ground  communication  equipment. 

Although  organizationally  separate  from  AFSPC,  the  Electronic  Systems  Center  (ESC)  Detachment  5 
(Det  5)  will  also  be  a  user  of  the  VSLRC.  ESC  Det  5  provides  support  to  the  Integrated  Tactical  Warning 
and  Attack  Assessment  network  to  North  American  Aerospace  Defense  Command  (NORAD),  United 
States  Space  Command  (USSPACECOM),  and  United  States  Strategic  Command  (USSTRATCOM). 

Private  contractors  and  other  DoD  services  also  play  important  roles  in  space  systems  management,  and  at 
a  minimum  will  serve  as  data  sources  to  the  VSLRC. 

3.2  Stakeholder  and  User  Identification 

Stakeholders  and  users  of  the  VSLRC  are  described  in  the  table  below.  The  role,  office  symbol,  overall 
description,  and  responsibilities  as  they  pertain  to  the  VSLRC  are  provided. 


Role 

Office  SymboKs) 

Description 

Responsibility 

Commander,  CISF 

SMC  Det  1 1 

Commander  responsible 
for  logistics  readiness, 
infrastructure  support, 
and  sustainment  of 
space  systems 

Facilitates  weekly 
Production  Work  Group 
meetings 

Participates  in  quarterly 
briefings  to  Chief 
Sustainment  Officer 
Provide  initial  funding 
for  VSLRC 

SSM 

SMC  Det  1 1  CWS,  CID, 
CWD,  CZG,  MCL, 

MTL 

Responsible  for  overall 
long-term  system  health 

Presents  at  weekly 
Production  Work  Group 
meetings 

Presents  at  quarterly 

CSO  briefings 

Presents  yearly  SEMR 

SSM  Support  Staff 

SMC  Det  1 1  4-digits 
under  SSMs 

Responsible  for 
supporting  SSM  by 
monitoring  weekly  and 
monthly  sustainment 
issues 

■  ■■  '  c -  tt _ _ 

Collect  supply  and 
maintenance  data  daily 
Present  weekly  reports 
on  system  status  and 
issues 

Recommend  corrective 
action  for  short-  and 
mid-term  problems 

Support  Wings  in  daily 
operations  when 
necessary 

Numbered  Air  Force 
(NAF)  A4 

Example:  14'"  AF  A4 

Responsible  for  support 
and  management  of 
logistics  and 

Create  daily  and  weekly 
MICAP  reports 

Produce  daily  and 
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Role 


Office  Symbol(s) 


Description 


Responsibility 


sustainment  activities  to 
Wings,  interface  with 
the  AOC 


weekly  AOC  briefing 
(Intel  report)  containing 
operations  and  logistics 
status 


NAF  Air  Operations 
Center  (AOC) 


Example:  14h  AF  AOC 


Responsible  for  reach 
back  to  theater;  single 
point  of  contact  for 
anything  related  to 
Space  systems;  focused 
on  daily  problems 


Collect  and  report 
detailed  logistics  status 
from  space  systems 
operators  on  a  daily 
basis 


Wing-Level  Operator 


Example:  50th  Wg/ 
OG/OGV 


Responsible  for 
operating  space  systems, 
providing  capability  to 
warfighter 


Will  provide  real-time 
operational  status 


Wing-Level 
Maintenance  Officer 


Example:  50  WG/  850 
SCS/SCOor21  MX 
Ops  Flight 


Responsible  for  and 
2"^  levels  of 
maintenance  on  space 
systems 


Will  provide  real-time 
maintenance 
information  to  CAMS 
and  other  organizations 


Wing-Level  Logistics 
Readiness  Officer 


Example:  Petersen  AFB 
Supply 


Responsible  for  retail 
supply,  transportation, 
and  other  readiness 
functions 


Will  provide  MICAP 
information  to  CAMS 
and  other  organizations 


Supply  Chain  Manager 


Example:  OO-ALC/LHJ 


Provides  administration, 
program,  technical, 
engineering,  inventory 
and  production  expertise 
and  support  to  Space 
and  C3I  System  Support 
Managers _ 


Provide  input  to  CSO 
briefings,  sustainment 
working  groups,  SEMR, 
and  Det  1 1  on  organic 
sustainment  support  to 
Space  Systems 


Item  Manager 


Example:  00- 
ALC/LHPJB 


Focal  point  for  all 
inventory  management 
functions 


Oversee  and  manage 
requisitions  for  Space 
systems;  review  and 
upgrade/downgrade 
Backorders  and 
MICAPS 


Logistics  Management 
Specialist 


Example:  OO- 
ALC/LHPJB 


Plans,  manages,  and 
coordinates  supply  chain 
and  logistics  support  for 
a  major  weapon  system 


Provide  input  to  CSO 
Briefings,  SEMR,  and 
Det  1 1  on  maintenance 
and  sustainment  issues; 
Review  and  comment  on 
quarterly  Supply  Efrivers 
and  Bad  Actors 


Equipment  Specialist 


Example:  00- 
ALC/LHPJC 


Establishes  maintenance 
schedules,  plans  and 
requirements,  such  as 
selection  and  utilization 
of  support  equipment, 
levels  at  which  repair 
will  be  performed  for 
weapon  systems,  and 
work  to  be 


Review  technical 
problems  and 
determines  and  initiates 
corrective  action; 
communicates  with 
SSM  and  units  on 
system  modifications 
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Role 

Description 

accomplished  as  a  result 
of  modification  projects 

Production  Management 
Specialist 

Example:  00- 
ALC/LHPJC 

Reviews  negotiated 
schedules,  material 
supportability  listings, 
material  shortage 
reports,  labor  and 
material  plans, 
production  orders  and 
work  requests,  to 
determine  if  manpower, 
material,  facilities,  test 
equipment  and  technical 
data  are  available  and 
sufficient  to  accomplish 
work  load  in  keeping 
with  negotiated 
schedules 

Expedite  repair  for 

MICA  PS,  review  repair 
status  of  items  with  on 
and  off-site  repair  shops 

HQ  Operations  Center 

Example  ~  Space 
Operations  Center 

Plan,  monitor  and  assess 
the  execution  of  space 
assets  and  systems 
worldwide 

Providing  integrated 
real-time  weapon 
system  status  reporting 
for  entire  AF  Space 
Command 

HQ  System  Support  / 
Logistics  Readiness 
Officer  and  Analyst 

Example  -  HQ 
AFSPC/LCRPC  and 

LCN 

Report  daily  system 
status;  drive  expedited 
maintenance  or  supply 
actions;  view  monthly 
system  health  metrics 

Regular  analysis  of 

Space  system  health, 
Troubleshoot  and 
resolve  equipment 
issues  based  on 
system/asset  visibility 

3.3  Key  Stakeholder  and  User  Needs 


Need 

Current  Solution 

Proposed  Solution 

Visibility  of  operational, 
equipment  and  comm, 
status 

Collect  data  and  manually 
manipulate  into  Power 
Point  presentations 

Automatically  pull  near  real-time 
information  and  display  on  a 
single  screen  (one  per  system) 

Visibility  of  logistics 
and  maintenance  impact 
on  operational  readiness 

Collect  data  manually 
from  Situation  Reports 
(SITREPS),  phone  calls, 
or  CAMS  Equipment 

Status  Reports  (ESRs), 
and  enter  into 
spreadsheets,  reports, 
and/or  PowerPoint 
presentations 

Link  operational  readiness 
indicator  to  detailed  logistics  and 
maintenance  information  via  data 
integration  and  interactive  drill¬ 
down  capability 

Collection  of 
maintenance  and 
logistics  data  that 
support  metrics 
calculation 

Information  is  contained 
in  disparate  system 
databases  and  manually 
integrated  when  needed 

Pull  data  from  the  EDW  or 
outside  systems  via  adaptors 
(contractor/other  service) 

Instant  notification  of 
critical  logistics  problem 

Notification  is  not  instant; 
those  that  need  to  know 

Produce  messages  and  alerts  to 
which  system  users  can  subscribe 
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Visibility  of  item  status, 
location,  and  disposition 


Drill-down  from 
equipment  status  to 
underlying  causes 


Current  Solution 


must  wait  for  reports  or 
make  phone  calls 


Access  several  systems  to 
research 


Must  manually  research 
in  CAMS 


Proposed  Solution 


Pull  key  information  from 
different  systems  into  a  single 
screen 


Select  equipment  status  for  a 
particular  system  and 
automatically  retrieve  causal 
details 


Integration  with 
Balanced  Scorecard 


No  current  solution  exists 


Produce  MICAP 
Reports 


Determine  overall 
equipment  status  based 
on  status  of  system 
components 


Identify  top 

maintenance  and  supply 
drivers 


Conduct  single  point 
failure  (SPF)  analysis 


Produce  Unit,  Wing,  and 
NAF  SITREPs 


Track  and  store  actions 
being  taken  to  solve 
logistics  problems  as 
they  pertain  to  systems, 
components,  items,  etc. 


Inform  theater 
commanders  of  critical 
operations  and  logistics 
outages  that  could 
impact  operations 


Manually  produced  using 
some  automated  data 
collection,  manual  data 
collection,  Excel  and 

Power  Point  charts _ 

No  current  solution  exists 


Manually  produced  with 
no  consistent 
methodolo 


Manually  produced  and 
distributed;  phone  calls 
often  needed  for 
clarification 


Manually  stored  in  stove- 
piped  systems  or 
individual  offices  if  and 
when  recorded 


Commanders  informed 
on-the-fly  and  in  ad-hoc 
fashion  via  phone  calls  or 
email 


Balanced  Scorecard  (BSC)  is  a 
separate  but  related  effort  to 
VSLRC,  BSC  will  report 
systems’  status  and  metrics  to 
senior  management  through 
stoplight  charting.  It  is 
anticipated  that  the  VSLRC  will 
provide  supporting  data  and 
analytical  capability  to  the  BSC 


Establish  interfaces  with  SBSS, 
CAMS,  and  D165B  to  produce  an 
automated  report  of  MICAPS  and 
operational  impacts 

Methodology  to  be  built  into 
CAMS  and  reported  through  the 
VSLRC 


Use  tailored  business  rules  to 
define  and  automatically  identify 


Use  tailored  business  rules  to 
define  and  automatically  identify 


Produce  SITREPS  from  real-time 
data,  and  use  business  rules  to 
roll-up  and  consolidate  based 
upon  organization  and  echelon 


Record  “Actions  Taken” 
comments,  and  permanently 
associate  with  systems  and  assets 
until  resolution  has  been  reached; 
store  history  for  reference 
purposes 


Produce  automated  alerts  that 
inform  all  theater  command 
stakeholders  of  potential  impacts 
to  combat  operations 


3.4  Use  Case  Identification 

Several  use  cases  will  be  developed  to  describe  how  the  VSLRC  will  support  user  needs.  These  use  cases 
include,  but  are  not  limited  to: 

•  View  Current  System  Status 

•  View  Quarterly  Top- 10  Space  Supply  Drivers  List 

•  Alert  Supply  Chain  of  Critical  Logistics  Problem 

•  View  MICAPS 

•  Research  Item 

•  Conduct  Trend  Analysis  of  System  Performance  Measures 

Data  sources  relative  to  specific  functions  within  the  use  case  are  identified  within  the  use  case. 

3.4.1  View  Current  System  Status 
Brief  Description 

Decision-makers  in  the  GPS  supply  chain  need  to  know  the  real-time  operational,  ground  equipment,  and 
communications  equipment  status  of  existing  GPS  systems.  They  also  need  to  know  underlying  causes  of 
the  system  status,  so  they  can  determine  what  steps  should  be  taken  to  make  systems  fully-mission 
capable. 

Flow  of  Events 
Basic  Flow 
Use  Case  Start 

This  use  case  starts  when  the  14"’  AF  AOC  (orNAF  AOC)  Officer  accesses  the  VSLRC  to  see  current 
status  of  the  GPS  systems.  The  user  then  selects  GPS  from  the  list  of  space  systems. 

Display  Current  System  Status 

The  VSLRC  returns  the  following  information  in  stoplight/color-coded  fashion: 

•  For  each  system  -  the  Operational  Status,  Ground  Equipment  Status,  and  Communications 
Equipment  Status 

-  Status  will  be  either  fully  mission  capable  (FMC),  Partially  Mission  Capable  (PMC),  or 
Non-Mission  Capable  (NMC) 

-  FMC  will  be  green,  PMC  amber,  NMC  red 
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•  For  each  system  whether  or  not  it  is  scheduled  to  be  in-use  at  the  current  time 

-  Those  systems  that  are  not  scheduled  to  be  in-use  at  the  current  point  in  time  will  still 
have  the  appropriate  color  code,  but  will  be  noted  as  not-scheduled  (possibly  with  an  X 
through  the  applicable  status  box) 

-  Systems  that  are  not  scheduled  to  be  in-use  will  be  undergoing  scheduled  modifications, 
maintenance,  or  testing 

•  Please  refer  to  Figure  3 . 1  for  a  depiction  of  the  “systems”  that  need  to  be  displayed  for  the 
GPS 

Show  Additional  Detail 

The  AOC  Officer  will  be  able  to  select  the  system  status  designation,  and  in  doing  so  request  more  detail. 
It  is  presumed  that  he/she  will  only  select  an  “amber”  or  “red”  system.  After  the  selection  has  been  made, 
the  user  will  see  the  following  information  about  that  portion  of  the  system: 

•  Reason  for  the  status 

•  What  is  the  operational  impact 

•  Subsystems  or  components  impacting  the  status 

•  Estimated  Time  to  Return  to  Operations 

•  Whether  or  not  a  MICAP  exists 

-  If  a  MICAP  does  exist,  who  is  working  on  getting  the  part,  from  where  will  the  part 
come,  when  is  it  expected 

Create  Report 

The  AOC  Officer  may  wish  to  create  a  report  for  the  GPS  system  status.  The  VSLRC  can  print  the 
report,  or  it  can  save  it  in  an  electronic  format  that  is  easily  exportable  to  MS  Power  Point  or  MS  Excel. 

Use  Case  End 

At  this  point,  the  user  may  go  back  to  viewing  the  status  for  other  systems  and  the  use  case  is  complete. 
Alternate  Flow 

•  The  AOC  Officer  must  contact  the  Wing  or  the  Unit  for  further  information  about  the  system 
status  -  The  user  may  choose  to  call  via  phone  and  enter  the  required  information  into  the 
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VSLRC  at  this  point  -  Or,  he/she  may  send  an  alert  using  the  VSLRC  to  the  intended  person 
requesting  that  they  enter  information  directly  into  the  VSLRC  at  the  Unit  or  Wing 

•  The  user  is  the  14*’’  AF  A4,  and  wants  additional  information  about  a  particular  system  after 
looking  at  current  system  status  and  status  detail  -  He/she  would  like  to  see  historical 
information  to  see  if  there  is  a  trend  developing  for  a  particular  system  that  needs  to  be 
addressed 

•  The  user  is  the  GPS  SSM,  and  instead  of  selecting  the  GPS  from  a  list  of  systems,  he/she 
wants  the  default  view  to  contain  only  status  on  the  GPS 

Special  Requirements 
Handling  of  Classified  Information 

The  information  handled  by  this  use  case  is  normally  considered  Classified  -  Secret.  The  VSLRC  must 
ensure  the  information  is  not  compromised. 

•  Pre-conditions 

VSLRC  access  to  real-time  CAMS  Data 

-  VSLRC  access  to  real-time  LogBook 

-  Business  rules  exist  in  VSLRC  to  determine  FMC,  PMC,  NMC 

-  VSLRC  access  to  real-time  SBSS 

-  VSLRC  access  to  real-time  D035K 

-  Other  actors  have  access  to  VSLRC  (Unit,  Wing,  SCM) 

•  Post-conditions 

-  VSLRC  saves  added  information 

-  VSLRC  alerts  other  actors  that  additional  information  is  needed 

•  Extension  Points 

-  Establish  User  Account 


User  accesses  the  VSLRC 


The  following  figure  (Figure  3-1  VSLRC  GPS  Control  Segment  Core  Screen)  is  an  example  screen  of  a 
possible  solution  to  the  above  use  cases. 


HSH 


*ile  View  Links  Metrics  Reports  Tools  User  Settings  Heip 


MICAPS  I  Top  Supply  Drivers  I  i  r  -ik  ■  i.’i  s  I  Pfoductimp.  |  Funding 
P^Controi;  flatus  at  a  6  lanea  Vlsw  *  t  ^'Systam^Hsalth 


Figure  3-1.  VSLRC  GPS  Control  Segment  Core  Screen 


3.4.2  View  Quarterly  Space  Supply  Drivers  List 
Brief  Description 

HQ  AFSPC/LCR,  00-ALC/LHJ,  and  the  Space  SSMs  (Det  1 1)  are  required  to  report  and  manage  a  list 
of  top  Space  Supply  Drivers  (NSNs).  The  VSLRC  will  apply  a  pre-defined  mettiodology  to  produce  a 
baseline  list  of  candidate  top  supply  drivers,  provide  the  user  with  the  capability  to  analyze  the  baseline 
list,  and  then  modify  the  list  based  on  the  analysis. 


Flow  of  Events 
Basic  Flow 
Use  Case  Start 

This  Use  Case  starts  when  tiie  SSM  chooses  to  look  at  the  current  list  of  quarterly  Supply  Drivers  for 
his/her  system.  The  user  has  already  specified  his/her  role  (SSM),  and  system  (for  this  example,  the  GPS) 
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Flow  of  Events 


Basic  Flow 
Use  Case  Start 

This  Use  Case  starts  when  the  SSM  chooses  to  look  at  the  current  list  of  quarterly  Supply  Drivers  for 
his/her  system.  The  user  has  already  specified  his/her  role  (SSM),  and  system  (for  this  example,  the  GPS) 
via  the  Establish  User  Account  use  case.  The  user  has  also  already  logged  into  the  VSLRC  before 
choosing  the  option  to  view  the  Supply  Drivers. 

Calculate 

By  selecting  the  option  to  view  the  top  Supply  Drivers  list  for  the  GPS,  the  SSM  asks  the  VSLRC  to 
identify  the  candidate  items  based  on  current  (near  real-time)  data  for  the  most  recent  completed  Fiscal 
Year  (FY)  quarter.  The  VSLRC  uses  the  following  methodology  to  identify  the  candidate  items: 

(Note  -  this  methodology  will  probably  change  over  time) 

1)  Identify  NSNs,  by  system,  for  which  wholesale  requisitions  have  been  placed  during  the  last  whole 
fiscal  year  quarter.  Fiscal  year  quarters  are  defined  as: 

•  1  Oct-31  Dec(FYxxxxQl) 

•  1  Jan  -  3 1  Mar  (FYxxxx  Q2) 

•  1  Apr  -  30  Jun  (FYxxxx  Q3) 

•  1  Jul  -  30  Sep  (FYxxxx  Q4) 

2)  For  this  list  of  NSNs,  the  VSLRC  will  assign  the  following  weights: 

a)  MICAP  Score 

i)  NSN  had  0  MICAPS  during  the  quarter,  score  =  0 

ii)  NSN  had  1  or  more  MICAPS  during  the  quarter,  score  =  .5  +  (.5  *  number  of  MICAPS 
incidents  for  the  NSN  during  the  quarter) 

Hi)  Score  cannot  be  >  2.5 

b)  Hits  Score 

i)  Score  =  .  1  *  number  of  hits  during  the  quarter 

ii)  Score  cannot  be  >  2 

c)  Single  Point  Failure  item  (SPF)  Score 
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i)  If  the  NSN  is  classified  as  a  Single  Point  Failure  item,  score  =  2.0 

ii)  Otherwise,  score  =  0 

d)  Vanishing  Vendor  (VA^)  Score 

i)  If  the  NSN  is  classified  as  a  Vanishing  Vendor  item,  score  =  1 .5 

ii)  Otherwise,  score  =  0 

e)  Backorder  Score 

i)  If  the  NSN  has  any  open  backorders  against  it  on  the  last  day  of  the  quarter,  score  =  .2 

ii)  Otherwise,  score  =  0 

f)  Overall  Score  =  MICAP  Score  +  Hits  Score  +  SPF  Score  +  V/W  Score  +  Backorder  Score 

g)  Rank 

i)  The  number  one  ranking  item  (i.e.,  the  number  one  supply  driver)  is  the  NSN  with  the  highest 
overall  score 

Note  -  as  of  9  July  2003  these  business  rules  were  under  review  for  possible  revision.  A  new  algorithm 
may  be  developed  that  considers  MICAP  hours,  backorder  duration,  and  possible  Issue  Effectiveness. 

Return  List  of  Top  20 

Once  the  calculation  is  complete,  the  VSLRC  will  return  as  a  default  the  candidate  list  of  items  for  the 
system  as  a  whole,  regardless  of  the  item’s  source  of  supply  or  repair  (SOS/SOR)  (as  opposed  to  only  the 
candidate  items  that  are  managed  by  00-ALC  for  example).  The  list  of  items  is  sorted  by  Rank  in 
ascending  order  for  items  with  Rank  value  of  1  —  20.  In  addition  to  showing  the  NSN  and  the  Rank,  the 
VSLRC  will  also  show  the  following  information  at  this  point: 

•  Noun  (for  the  N  SN) 

•  SOS  (for  the  NSN) 

•  Overall  Score 

•  MICAP  Score 

•  Hits  Score 

•  SPF  Score 

•  WN  Score 
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backorder  detail,  and  various  NSN  catalogue  information  like  Interchangeable  and 
Substitution  Group  (I&SG),  Expendability,  Recoverability,  Reparability  Code  ((ERRC),  etc.) 
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Figure  3-3.  Top  Ten  Additional  Detail 
Defer  Item  and/or  Add  Working  Detail 

After  reviewing  the  list,  the  SSM  may  decide  that  one  or  more  NSNs  do  not  really  warrant  being  on  the 
list  of  supply  drivers.  This  will  be  based  on  that  user’s  expert  determination  after  reviewing  all  of  the 
supply  information  available  in  the  VSLRC  about  the  item(s)  in  question.  For  each  of  these  items,  the 
SSM  will  tell  the  VSLRC  that  he/she  wishes  to  “defer”  the  item  from  the  list.  He/she  must  then  tell  the 
VSLRC  why  and  for  how  long  the  item  should  be  deferred.  The  VSLRC  will  save  this  information,  and 
make  it  available  to  any  other  VSLRC  user  who  is  requesting  information  about  that  NSN. 

For  any  of  the  items  (deferred  or  not),  the  SSM  may  wish  to  add  comments  about  what  he/she/others  are 
doing  to  take  action  to  get  the  NSN  off  of  the  list.  The  VSLRC  will  save  this  information  as  well,  and 
make  it  available  to  other  VSLRC  users  who  are  researching  that  item. 


Use  Case  End 

This  use  case  ends  when  the  SSM  tells  the  VSLRC  it  is  done  reviewing  the  candidate  list.  Upon  request, 
the  VSLRC  will  notify  others  who  wish  to  see  the  GPS  supply  drivers  list  (regardless  of  selection  criteria) 
that  the  SSM  has  reviewed  and  finalized  the  list. 

Alternate  Flow 

•  View  “Current”  list  of  supply  drivers  where  user  specifies  a  date  (i.e.,  over  past  week  or  2 
months,  etc.)  vs.  the  last  complete  FY  quarter  -  Users  have  said  that  the  supply  drivers  list 
isn’t  of  much  use  if  done  more  frequently  than  quarterly,  but  there  was  some  discussion  about 
being  able  to  access  data  that  is  more  current  and  therefore  “predictive” 

•  Look  at  NSNs  that  have  been  on  the  supply  drivers  list  for  more  than  one  FY  quarter  in  the 
past  2  years 
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•  View  historical  trends  for  NSNs  on  the  supply  drivers  list  (i.e.,  MICAP  information  for  the 
past  2  years)  (Reference  Figure  3-4  Top  Ten  Historical  Trends) 

•  Add  comments  regarding  Acton  Taken  to  the  Historical  Trends  chart  (Figure  3-4) 

•  View  only  the  deferred  items,  along  with  their  deferment  history 

•  Look  at  Top  10  list  according  to  criteria: 

-  Entire  system 

-  Sorted  by  SOS 

-  Sorted  by  MAJCOM 

•  Role-based  changes 

-  If  role  is  GPS  Log  Mgt  Spec  (LMS),  then  will  default  to  list  for  LHJ-managed  items 

-  If  role  is  AFSPC/LCR,  then  will  default  to  list  for  AFSPC 
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_ _ _ ,, _ _ _ _ _ _ _ 
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7 
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FY2002  Q3 

3 

R 

#  of  MICAPS,  hits,  and  B/0 

FY2002  Q4 

1 

V 
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Figure  3-4.  Top  Ten  Historical  Trends 


Special  Requirements 

•  Pre-conditions 

-  None 

•  Post-conditions 

-  VSLRC  saves  information  that  was  added  about  the  NSN  (i.e.,  in  deferment) 

-  VSLRC  alerts  other  users  that  the  quarterly  list  has  been  reviewed  by  the  SSM 
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Extension  Points 

-  Establish  User  Account 

-  User  accesses  the  VSLRC 

Alert  Supply  Chain  of  Critical  Logistics  Problem 

There  are  several  situations  that  will  trigger  the  VSLRC  to  send  instant  notifications  or  “alerts”  to 
VSLRC  users.  Alerts  will  notify  users  that  a  condition  exists  that  may  require  immediate  or  fast  attention, 
and  are  meant  to  inform  as  well  as  promote  action.  There  are  three  potential  ways  in  which  the  VSLRC 
will  know  which  users  to  send  alerts  to  and  when: 

•  Users  subscribe  to  receive  certain  types  of  alerts  (e.g.,  a  user  requests  that  the  VSLRC  notify 
him/her  when  a  performance  measure  breaches  a  particular  threshold) 

•  The  system  automatically  subscribes  the  user  to  alerts  based  on  his/her  role  (e.g.,  SSM 
Support  Staff  will  always  receive  alerts  of  critical  logistics  problems  that  happen  out  of  the 
SITREP  cycle) 

•  One  user  will  set  up  a  subscription  for  another  user  (e.g.,  a  user  requests  that  specific 
individuals  receive  an  alert  on  a  weekly  basis  when  a  custom  report  is  created) 

While  more  extensive  requirements  research  and  analysis  needs  to  be  conducted  to  identify  all  possible 
alerts  and  their  role  associations,  the  following  list  summarizes  the  alerts  identified  to-date: 

•  Alerts  of  specific  conditions: 

-  Critical  outage  for  a  Space  system  has  occurred  (can  be  operational  or 
logistics/equipment) 

-  MICAP  exists  that  is.driving  a  critical  outage 

-  Performance  measure  just  breached  a  critical  threshold  and  warrants  attention 

-  MICAP  exists  for  items  classified  as,  but  not  being  used  as,  support  equipment 

-  Critical  spare  has  been  retrograded  to  SOR,  but  has  not  yet  been  inducted  into 
maintenance 

-  Due-out  exists  with  no  corresponding  Due-in 

•  Alerts  that  reports  are  ready  for  review: 

-  Top-1 0  Supply  and/or  Maintenance  Drivers 
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SITREPS 


-  MICAPS 

-  System  Status 

-  Custom-created  Reports  for  regular  distribution  (e.g.,  weekly  GPS  report  created  by 
SSM) 

•  Directly  from  the  VSLRC  -  the  user  will  be  alerted  while  logged  into  and  using  the  VSLRC 

-  Alert  messages  will  appear  on  the  user’s  screen,  regardless  of  what  he/she  is  doing  in  the  VSLRC 
(e.g.,  a  message  will  appear  at  the  bottom  of  the  screen  stating  the  user  has  3  new  alerts) 

-  Alert  messages  will  be  accessible  via  an  alerts  page  (or  screen)  that  will  contain  all  of  the  user’s 
active  alerts  -  read  or  unread.  This  page  will  contain  the  following  information  for  each  active 
alert: 

Description  of  the  alert 

If  it  has  been  read  or  if  it  is  new/unread 

Original  date  of  the  alert 

Number  of  days  it  has  been  active 

Other  information  TBD 

A  link  to  view  additional  detail  about  the  alert 

•  Via  email  -  the  user  can  be  alerted  via  email  in  addition  to  directly  from  the  VSLRC 

-  If  the  alert  is  a  simple  text  message,  it  will  appear  in  the  email 

-  If  the  alert  contains  a  report  or  graphics  that  the  VSLRC  generated,  these  can  be  embedded  in  the 
email,  or  the  email  can  contain  a  link  to  that  report/graphic 

•  Other  -  the  VSLRC  may  also  be  able  to  alert  users  via  cell  phones,  pagers,  and  other  hand-held 
devices  in  addition  to  directly  from  the  VSLRC 

It  is  important  to  note  that  one  alert  may  be  sent  to  multiple  VSLRC  users.  A  notional  depiction  (Figure 
3-5.  Alert  Detail)  of  an  Alerts  page  and  subsequent  Alert  detail  is  provided  at  the  end  of  this  use  case  for 
example  purposes  only.  While  an  alert  is  active,  the  user  can  view  it  and  all  associated  information.  Users 
can  also  make  note  of  and  track  the  actions  being  taken  to  resolve  the  alert.  For  example,  if  a  critical 
outage  exists  because  of  a  MICAP  problem,  the  Item  Manager  can  make  note  that  he/she  is  seeking  an 
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Once  a  user  has  received  an  alert,  he/she  must  normally  take  action  to  resolve  it.  In  the  case  of  a  report, 
the  user  must  simply  view  the  report  before  the  alert  is  removed  from  the  user’s  list  of  active  alerts,  hi  the 
case  of  a  condition,  the  alert  will  not  become  inactive  until  the  condition  that  prompted  the  alert  has  been 
resolved. 
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Figure  3-5.  Alert  Detail 


Brief  Description 

The  14*  AF  AOC  Officer  is  required  to  present  a  list  of  current  AF  Space  system  MICAPS  and  their 
respective  status  to  their  commander  and  to  HQ  AFSPC,  because  MICAPS  may  have  an  impact  on  a 
space  system’s  operational  capability.  They  are  particularly  interested  in  knowing  if  a  MICAP  is  causing 
a  system  to  have  a  non-mission  capable  Operational  Status  (Ops  Cap  “Red”),  and  what  action  is  being 
taken  to  correct  (“fill”)  the  MICAP. 


Flow  of  Events 


Basic  Flow 


Use  Case  Start 

This  use  case  begins  when  the  AOC  Officer  actor  asks  the  VSLRC  to  display  current  MICAPS  for  AF 

Space  Command.  The  AOC  Officer  will  want  to  see  all  current/active  MICAPS  on  a  daily  basis,  by  each 
AF  Space  system: 

•  Defense  Support  Program  (DSP)  Ground  Segment 

•  Mars  Global  Surveyor  (MGS) 

•  Missile  Warning  Radar 

•  GPS 

•  Military  Satellite  Communications  MILSATCOM  Ground  Station  Segment 

•  Deep  Space  Tracking  System  (DSCS) 

•  Air  Force  Satellite  Control  Network  (AFSCN) 

•  Space  Range 

•  Space  Surveillance  Network 

The  View  MICAP  Information 

For  the  AOC  Officer,  the  VSLRC  will  provide  the  following  information  for  MICAPs  for  each  system: 

•  System  Name  (i.e.,  GPS) 

•  System  Site 

•  System  Identifier  (not  sure  what  this  or  if  it’s  needed) 

•  System  Status  (see  use  case  for  View  System  Status) 

•  MICAP  Item  Name  (i.e.,  NSN  noun) 

•  Item  Quantity 

•  MICAP  Start  Date 

•  MICAP  Hours  To  Date 

•  MICAP  Status  and  Location  (e.g.,  is  it  on  contract  through  00-ALC,  on  backorder  at  WR- 
ALC,  in  repair  at  00-ALC,  in-transit  from  contractor,  etc.) 

•  Estimated  Time  of  Return  to  Operations 
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Within  each  system,  the  default  sort  order  will  be  from  newest  MICAP  to  oldest.  The  VSLRC  will  also 
tell  the  14"’  AOC  user  which  MIC  APS  are  new. 

It  is  possible  that  another  user  (from  the  Wing,  Unit,  SSM,  SCM,  etc.)  has  entered  comments  into  the 
VSLRC  about  this  MICAP  (e.g.,  what  other  steps  are  they  taking  to  solve  the  problem,  is  there  a  similar 
problem  elsewhere,  etc.).  If  that  is  the  case,  the  VSLRC  will  make  this  known  to  the  AOC  user,  and 
he/she  will  be  able  to  view  the  comment(s). 

Enter  Additional  Detail 

At  times,  the  AOC  Officer  user  may  need  additional  detail  about  one  or  more  MICAPS.  The  VSLRC  will 
provide  the  AOC  user  with  contact  information,  and  he/she  can  contact  the  appropriate  person  (by  phone, 
email,  etc.).  Once  they  have  collected  the  additional  detail,  the  M*  AOC  user  will  be  able  to  enter  the 
information  into  the  VSLRC.  That  information  will  be  saved  in  the  VSLRC,  and  will  be  displayed  on  the 
list  of  MICAPS. 

Produce  MICAP  Report 

The  AOC  user  may  wish  to  produce  a  report  based  on  the  current  list  of  MICAPS.  This  report  may  be  in 
the  form  of  a  PowerPoint  presentation,  with  one  slide  for  each  system,  or  in  a  format  easily  exportable  to 
other  MS  Office  products  (Word,  Excel,  etc.).  The  user  may  wish  to  report  only  on  those  MICAPS  that 
are  associated  with  a  system  having  an  Ops  status  of  Red  or  Amber,  and  the  VSLRC  will  filter  out  the 
other  MICAPS. 

Use  Case  End 

This  use  case  ends  when  the  AOC  user  is  done  reviewing  the  list  of  MICAPS  and  either  navigates  to 
another  VSLRC  screen,  or  ends  his/her  session  with  the  system. 

Alternate  Flow 
Wing  as  Actor 

The  Wing  will  be  primarily  interested  in  MICAPS  associated  with  their  particular  systems  and  sites,  as 
opposed  to  all  systems  and  all  sites.  Even  though  the  Wing  will  be  able  to  view  all  MICAP  information, 
the  default  starting  point  for  the  Wing  will  be  a  report  showing  only  that  Wing’s  information. 

In  addition,  the  Wing-level  user  will  want  to  help  take  corrective  action  to  solve  the  MICAP  issue.  To  do 
this,  he/she  may  need  detailed  current  information  about  the  item  (NSN)  including  worldwide  asset 
position,  the  current  MICAP  requisition  detail,  and  the  number  and  status  of  backorders  if  any  exist.  To 
do  tliis,  the  VSLRC  will  provide  a  link  from  the  MICAP  information  to  the  Research  Item  page  for  that 
item  (see  Research  Item  Use  Case). 
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Based  on  this  information,  the  Wing  user  may  wish  to  enter  in  comments  about  the  MICAP,  and  the 
action  being  taken  to  solve  the  problem.  If  other  users  have  added  any  comments,  he/she  will  need  to  see 
that  information  as  well. 

Supply  Chain  Manager,  Item  Manager,  or  Logistics  Management  Specialist  as  Actor 
Similar  to  the  Wing,  this  user  will  only  be  interested  in  MICAPS  that  fall  under  his/her  management 
scope,  so  the  default  list  of  MICAPS  will  be  filtered  accordingly.  The  VSLRC  will  also  provide  a  link  to 
the  Research  Item  page  for  each  MICAP,  and  will  give  the  Supply  Chain  Manager  the  ability  to 
view/enter  comments. 

14*^AF/A4 

The  14*^  AF  may  wish  to  see,  in  addition  to  the  list  of  current  MICAPS,  a  MICAP  history  by  system  and 
by  item.  They  may  wish  to  see  trends  going  back  1  -  2  years. 

Special  Requirements 

Some  of  this  information,  particularly  the  current  Ops  Status  may  be  classified,  while  some  will  be 
unclassified.  All  data  must  be  handled  according  to  the  security  classification  requirements. 

•  Pre-conditions 

-  None 

•  Post-conditions 

VSLRC  saves  information  that  was  added  about  the  MICAP. 

•  Extension  Points 

-  Establish  User  Account 

-  User  accesses  the  VSLRC 

-  Research  Item 

3.4.4  Research  Item 
3.4.4.1  Research  Item  for  GPS 
Brief  Description 

The  AF  Space  community  often  has  the  need  to  know  information  about  items  or  National  Stock 
Numbers  that  can  impact  the  decisions  they  make  about  supporting  Space  systems.  This  includes 
individuals  within  the  Supply  Chain  Management  organization  (e.g.,  OO-ALC/LHJ),  the  SSM 
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organization,  at  the  HQ  level,  at  the  M'*"  AF,  and  even  at  the  Wing  Level  and  below.  To  adequately 
research  a  particular  item,  information  from  several  disparate  data  systems  must  be  fused  to  provide  a 
cohesive  and  accurate  picture  for  the  decision-maker  (reference  Figure  3-6  Research  Item  Screen  - 
Notional  Example). 

Flow  of  Events 
Basic  Flow 
Use  Case  Start 

This  Use  Case  starts  when  the  Item  Manager  receives  a  MICAP  requisition  for  a  GPS  item,  and  tells  the 
VSLRC  that  he  needs  to  research  the  item  by  choosing  thatNSN  from  a  pull-down  list. 

View  Research  Screen 

The  VSLRC  returns  a  research  screen  that  incorporates  key  information  available  about  that  item, 
including  the  following; 

•  The  NSN  (or  National  Item  Identification  Number  NIIN),  Noun,  Part  Number,  Commercial 
and  Government  Entity  (CAGE),  and  past  deleted  Part  Numbers 

•  Item’s  Source  of  Supply,  Expendability,  Recoverability,  Reparability  Code  (ERRC), 
Acquisition  Advice  Code,  Unit  of  Issue,  Item  Manager  Code,  Equipment  Specialist,  and 
Demand  Level 

•  Whether  or  not  the  item  is  classified  as  a  VfV  or  SPF  item 

•  SOR,  alternate  SORs,  SORs  that  have  been  used  in  the  past 

•  The  item’s  I&SG  family 

•  Outstanding  Document  Numbers,  to  include  the  quantity,  priority.  Required  Delivery  Date 
(RDD),  project  code,  need  date,  and  record  date 

•  Outstanding  Requisitions,  to  include  requisition  number,  suffix,  quantity,  status,  Estimated 
delivery  Date  (EDD) 

•  The  item’s  Reorder  Point  (ROP),  Price,  Acquisition  Lead  Time,  and  Production  Lead  Time 

•  Any  existing  Purchase  Requests  (PR),  to  include  PR  numbers,  quantities,  and  RDD 

•  Past  purchase/contracting  history  for  the  item 
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•  Others  TBD' 

A  notional  Research  Item  screen  has  been  included  at  the  end  of  this  use  case  for  example  purposes. 

View  Backorder  Information 

If  the  item  has  been  backordered,  the  user  will  be  able  to  view  backorder  information,  to  include: 

•  NSN(orNIIN) 

•  Total  number  of  backorders 

•  Total  AWP 

•  Total  Joint  Chief  of  Staff  (JCS)-  War  Readiness  Material  (WRM) 

•  Total  backordered  MICAPS 

•  Total  in  Priority  Group  1  (Pri  1  -  3) 

•  Total  in  Priority  Group  2  (Pri  4-6) 

•  Total  Routine  backorders 

•  Total  WRM 

•  Total  yearly  backorder  quantity 
Include  Note 

If  the  Item  Manager  knows  some  information  about  this  item  that  is  not  depicted  on  this  screen,  or  that 
he/she  can  ascertain  by  looking  at  the  information  on  this  screen,  the  user  can  include  a  note  that  will  be 
saved  by  the  VSLRC  along  with  this  item. 

Use  Case  End 

This  use  case  ends  when  the  user  navigates  away  from  the  Research  Item  screen. 

Alternate  Flow 

None  at  this  time 

Special  Requirements 

•  Pre-conditions 


'  Note  -  due  to  time  constraints,  the  exact  requirements  for  the  Research  Item  page  were  not  specified  during  this 
effort.  Further  interviews  and  research  must  be  done  with  members  of  the  AF  Space  community  to  determine  the 
exact  requirements  for  this  screen. 
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•  Post-conditions 


-  VSLRC  saves  information  that  was  added  about  the  NSN  and  makes  that  information 
available  to  all  other  VSLRC  users  who  are  looking  at  that  NSN 

•  Extension  Points 

-  Establish  User  Account 

-  User  Accesses  the  VSLRC 
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Figure  3-6.  Research  Item  Screen  -  Notional  Example 


3.4.5  Conduct  Trend  Analysis  of  System  Performance  Measures 
3.4.5. 1  Trend  Analysis  and  Reporting 
Brief  Description 

The  GPS  SSM  and  support  staffs  conduct  time-series  analyses  of  various  GPS  performance  indicators  on 
a  weekly  basis.  The  purpose  of  the  trend  analyses  is  to  determine  if  action  needs  to  be  taken  to  solve  a 
problem  that  is,  or  could  become,  a  long-term  issue.  The  VSLRC  will  support  this  requirement  by 
calculating  and  displaying  a  series  of  metrics  in  time-series  format  (graphical  and  or  text-based)  for  the 
GPS  that  allows  the  user  to  drill-down”  into  underlying,  supporting,  and  perhaps  causal  detailed 
information  (Reference  Figures  3-7  -  3-13). 

Flow  of  Events 
Basic  Flow 
Use  Case  Start 

This  Use  Case  starts  when  the  actor,  GPS  SSM,  tells  the  VSLRC  that  he  wants  to  see  trends  for  GPS 
performance  measures. 

Select  Metrics,  Display  Format  and  Time  Frame 

The  VSLRC  presents  a  list  of  performance  measures  available  for  the  GPS. 

NOTE:  Refer  to  Appendix  A:  Metrics  Matrix  for  GPS  metrics 

The  actor  chooses  the  following  measures: 

•  Operator  Control  Station  (OCS)  Mission  Effectiveness 

•  Scheduled/Unscheduled  OCS  RED  Time 

•  Reasons  for  Unscheduled  RED  Time 

•  Reasons  for  Scheduled  RED  Time 

•  Satellite  Contact  Summary 

•  OCS  Operational  Status 

The  VSLRC  then  presents  the  actor  with  a  choice  of  display  formats:  1)  to  see  each  measure  on  its  own 
“page”,  or  2)  to  see  up  to  4  measures  on  a  single  page  at  one  time.  The  actor  chooses  the  following: 

•  OCS  Mission  Effectiveness  (on  its  own  page) 

•  Together  on  one  page: 
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Scheduled/Unscheduled  OCS  RED  Time 


-  Reasons  for  Unscheduled  RED  Time 

-  Reasons  for  Scheduled  RED  Time 

-  Satellite  Contact  Summary 

•  OCS  Operational  Status  (on  its  own  page) 

The  VSLRC  also  asks  that  the  actor  specify  a  date  range  and  frequency  for  these  measures,  and  the  actor 
specifies  that  he  wishes  to  see  the  series  in  weekly  increments  for  the  past  five  weeks.  The  VSLRC  then 
generates  the  requested  time-series  metrics. 

View  and  Analyze  Performance  Measures 

The  actor  can  choose  to  view  the  time-series  data  for  each  metric  in  tabular  format,  or  in  a  variety  of 
graphical  formats  (bar  charts,  column  charts,  line  charts,  etc.)  to  help  him  best  understand  the  information. 

In  this  case,  the  actor  wishes  to  see  more  detail  about  the  unscheduled  outages  that  ai;e  caused  by 
Automated  Data  Processing  Equipment  (ADPE).  He  selects  the  bar  on  the  Reasons  for  Unscheduled 
RED  Time  chart  for  ADPE,  and  the  VSLRC  provides  the  following  tabular  information  for  those  outages: 

•  Start  Time  (in  MM/DDA^YYY  HH:MM  format) 

•  Stop  Time  (in  MM/DDA^YYY  HH:MM  format) 

•  Site 

•  Duration  (in  hours  and  minutes  HH:MM  format) 

•  Reason 

•  Description 

The  actor  can  see  the  same  detail  for  Scheduled  RED  Time,  and  similar  information  for  Satellite  Contact 
Summary. 

While  viewing  this  detailed  information,  the  actor  can  record  notes  and  observations  about  the  outages 
that  can  be  saved  for  future  use  and  also  viewed  by  others. 

Save  and  Post  Report 

The  actor  can  save  the  pages,  notes,  and  detail  he  is  viewing  in  a  report  format  that  can  be  easily  viewed 
by  others.  He  can  also  include  the  notes  he  has  taken  as  a  result  of  his  analysis  that  describe 
recommendations  for  action,  or  further  descriptions  of  the  issues.  Once  the  report  has  been  saved,  he 
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specifies  those  VSLRC  users  he  wishes  to  send  it  to,  and  how  he  wants  them  to  access  it  -  either  by 
viewing  reports  through  the  VSLRC,  or  by  email.  The  VSLRC  posts  the  report  and  alerts  the  appropriate 
users  that  the  report  is  ready.  A  sample  report  is  provided  for  example  purposes  only  at  the  end  of  this 
use  case. 

Use  Case  End 

This  use  case  ends  once  the  report  has  been  posted. 

Alternate  Flow 

The  actor  may  not  want  to  create  a  report  at  this  time,  but  only  view  measures  and  conduct  analysis.  The 
actor  may  also  select  a  different  set  of  metrics  to  report,  different  display  formats,  different  time  series, 
etc. 

Special  Requirements 

Some  performance  measures  may  contain  classified/secret  information.  In  this  case,  the  VSLRC  must 
take  the  appropriate  security  measures  to  ensure  safe  handling  of  information. 

•  Pre-conditions 

-  None 

•  Post-conditions 

-  VSLRC  saves  the  report  for  users  to  access  at  future  dates 

•  Extension  Points 

-  Establish  User  Account 

-  User  Accesses  the  VSLRC 

•  Save  GPS  Report  Parameters  (i.e.,  use  this  to  access  a  report  with  the  same 
metrics  and  formatting  in  the  future,  only  refreshed  with  recent  data) 

Data  Sources 

Data  needed  to  support  this  use  case  include; 

•  CAMS  (possibly  through  the  EDW) 

•  Satellite  Contact  Summary  Sheet  (may  only  be  available  in  hard-copy  format) 

Data  needed  but  not  available  to  support  this  use  case  include: 
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Information  from  Defense  Information  Systems  Agency  (DISA)  regarding  the  number,  type, 
frequency,  duration  of  communications  equipment  outages 


General:  The  two  long-term  outage  issues  (the  TGA  at  the  Cape  and  the  Cape 

Monitor  Station)  are  still  being  worked.  There  was  less  than  20  hours  of 
unscheduled  downtime  recorded  across  the  OCS  with  no  sites  recording  less 
than  86%  mission  effectiveness. 


Remote  Sites : 

Cape  TGA:  The  TGA  went  through  operational  tests  yesterday  with  2  SOPS 
deciding  to  switch  back  to  the  Cape  GA  as  the  operational  resource  at  the 
Cape  when  the  TGA  had  troubles  with  uplink  signal  bleeding  over  to  the 
downlink  and  slow  uploads.  More  testing  is  being  planned. 

Cape  MS:  The  MS  is  still  AMBER  awaiting  a  replacement  HP5071  cesium  atomic 
frequency  standard  (CAPS) .  It  was  ordered  MICAP  and  the  published  estimated 
delivery  date  is  23  May.  The  MS  is  functional  but  in  OPSCAP  AMBER  due  to 
loss  of  redundancy. 


Jeffrey  S.  Wong,  Project  Engineer 
The  Aerospace  Corporation 

Det  11,  Space  and  Missile  Systems  Center  (AFSPC) 
CZG  &  CZS/NOSO  Support 


Figure  3-7.  SSM  Technical  Representative  Summary  Status  Via  E-mail 
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OCS  Summary  Graphs/Charts 
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Figure  3-8.  OCS  Summary  Graphs/Charts 
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Figure  3-9.  Details  of  Unscheluded  Outages 
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Figure  3-10.  Details  of  Scheduled  Outages 
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Figure  3-11,  SateUite  Contact  Summary 
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AMBER  time 


Figure  3-12.  OCS  Operation  Status 
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The  following  is  a  list  of  data  sources  that  meet  one  or  more  stakeholder  needs  and  their  associated  use  case. 
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4  Process  Flow  Diagrams 

Note:  Color  codes  are  representative  of  user  role  (e.g.,  unit,  wing,  14®,  etc.) 


Figure  4-1.  Notification  of  System  Outages  (Current) 
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5  Return  on  Investment  (ROI) 

The  Air  Force  Space  Command  logistics  processes  are  comprised  of  doctrine,  training,  personnel, 
organizations,  tools,  and  processes.  Currently,  these  components  do  not  act  together  in  an  integrated 
fashion  to  enable  an  effective,  efficient  method  to  ensure  the  optimum  operational  rates  are  maintained. 
Modem  business  reengineering  techniques  and  information  technologies  are  available  to  provide  a  robust, 
rationalized,  integrated  solution.  Skillful  application  of  these  technologies  and  techniques  is  necessary  to 
achieve  these  optimum  operational  rates.  A  web  portal  is  part  of  the  answer,  but  the  portal  needs  to  be 
complemented  by  solid  process  analysis  and  direct  linkages  between  the  process  analysis  and  the 
applications  available.  If  designed  correctly,  the  information  system  component  of  the  Air  Force  Space 
Command  logistics  processes  can  lead  to  appropriate  decision-making,  resulting  in  higher  operational 
rates. 

This  paper  has  described  a  vision  of  the  future  Air  Force  Space  Command  logistics  processes  and 
attempted  to  bring  that  vision  to  life  with  a  description  of  many  of  the  features  needed  in  the  VSLRC. 
There  is  still  much  work  to  do.  Process  models  need  to  be  developed  and  fully  coordinated.  The  entire 
Air  Force  Space  Command  logistics  process  has  to  be  evaluated  in  order  to  produce  the  necessary 
changes.  Design  of  tools  based  on  the  perspective  of  a  subset  of  the  stakeholders  will  yield  fragmented 
solutions  that  could  be  unresponsive  to  the  Air  Force  Space  Command  enterprise  goals.  The  priorities  for 
building  tools  and  the  scope  of  the  tools  (inputs,  outputs,  and  players)  need  to  be  specified  in  concert  with 
the  to-be  process.  A  solid  detailed  vision  is  a  necessity,  but  not  sufficient  condition,  for  change. 

The  application  of  enabling  technologies  such  as  a  web  portal,  a  distributed  component-based  software 
architecture,  and  Message  Oriented  Middleware  (MOM)  must  be  guided  by  a  To-Be  process  model 
conceived  from  an  entire  systems  perspective.  Without  a  direct  linkage  between  a  To-Be  process  and 
information  system  engineering  efforts,  the  Air  Force  Space  Command  is  destined  to  continue  to  expend 
resources  on  new  technologies  without  addressing  underlying  problems  with  the  total  Air  Force  Space 
Command  logistics  process.  Fragmented  information  system  efforts  cannot  solve  these  issues,  and 
choosing  new  technologies  -  even  the  right  technologies  -  alone  will  not  be  sufficient.  Each  process  needs 
to  be  defined  in  terms  of  inputs,  outputs,  and  players  to  ensure  all  tasks  contribute  to  the  overall  goal  of 
the  process  -  efficient  and  timely  application  of  Air  Force  resources  to  the  Air  Force  Space  Command 
mission. 

Achieving  the  vision  will  be  a  difficult  task.  Integration  techniques  used  for  complex  commercial 
enterprises  have  proven  it  is  possible.  Even  though  legacy  systems  do  not  always  work  together 
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cohesively,  many  offer  critical  capabilities  that  must  be  leveraged,  or  at  least  maintained,  during  transition 
periods. 

Some  of  the  Functional  Improvements  achieved  in  a  fully  developed  VSLRC  include; 

•  Resupply  becomes  more  efficient  because  requirements  are  identified  uniformly  among  all 
players  with  a  stake  in  the  mission 

•  Decision  support  allows  quick  determination  of  conflicting  demands  for  the  same  resources 
across  multiple  military  operations 

•  Tradeoffs  can  be  made  by  the  appropriate  stakeholders  having  access  to  the  applicable  data  to 
allow  them  to  de-commit  current  resources  to  higher  priority  efforts  and  reduce  the  amount  of 
report  generation 

•  Details  for  all  operations  will  be  consistent  and  readily  available  to  all  stakeholders, 
depending  on  their  role  and  responsibility 

•  Historical  data  can  be  kept  to  feed  subsequent  decision-making  processes 

•  Users  can  become  proactive  by  being  given  the  required/allowed  information  by  using  the 
Role-Based  Controls  -  Supplying  resources  will  be  based  on  the  overall  corporate  view  of 
requirements  versus  available  assets 

•  Supplying  resources  will  be  based  on  visibility  of  other  commitments  and  available 
capabilities  because  taskings  are  tracked  through  the  entire  logistics  process 

6  Technological  Environment 

6.1  Description 

Today’s  successful  application  is  characterized  by  several  complementary  key  factors.  It  is  one  that  is 
Web-based,  supports  disparate  databases,  is  not  a  stove-pipe  system,  but  rather,  a  loosely  coupled 
application  that  cooperates  with  other  applications  to  provide  an  enterprise  system,  provides  role-based 
security  to  components,  provides  a  customizable  front-end,  and  can  support  a  rapidly  changing 
environment. 

The  system  needs  to  be  Web-based  so  that  clients  can  access  the  application  with  minimal  client  software 
footprint.  Among  other  things,  this  thin-client  architecture  translates  to  lower  maintenance  costs,  in  both 
deployment  and  updates.  Web-based  applications  also  have  the  advantage  of  being  highly  portable  acro.SS 
heterogeneous  hardware  platforms.  If  the  client  hardware  supports  a  web-browser,  the  application  has  a 
high  probability  of  being  operated  at  that  site. 


49 


The  system  needs  to  support  disparate  databases.  VSLRC  will  undoubtedly  require  the  development  of 
its  own  database  to  store  some  data  to  support  trend  analysis  and  alerts.  However,  the  source  of  the 
majority  of  its  data  will  be  taken  from  a  multitude  of  other  application  and  legacy  databases.  The 
architecture  that  the  VSLRC  resides  must  be  one  that  can  easily  interface  with  these  disparate  databases 
and  yet  be  flexible  enough  to  obtain  its  data  from  other  sources,  such  as  the  Enterprise  Data  Warehouse 
(EDW),  as  required. 

The  system  needs  to  be  developed  as  a  component  of  a  larger  enterprise  application,  one  that  works  with 
other  interoperable  components.  The  employment  of  Message  Oriented  Middleware  (MOM)  and  the 
Publish/Subscribe  paradigm  enables  applications  to  eliminate  organizational  stovepipes  and  operate  as  a 
streamlined,  cohesive  enterprise. 

The  system  needs  to  provide  robust  web-centric  security  including  role-based  control  of  system 
components.  These  security  related  features  are  some  of  the  common  features  of  today’s  Portal 
environment,  an  environment  that  provides  user  customization  and  an  environment  that  is  expected  by 
today’s  consumers.  This  will  be  an  important  feature  to  the  VSLRC,  as  there  will  be  a  plethora  of  diverse 
roles  accessing  the  VSLRC  for  a  variety  of  reasons. 

To  successfully  deliver  an  application  with  the  above  stated  features  and  maximize  system  response  times 
and  efficiencies,  it  is  imperative  to  apply  the  appropriate  programming  standards.  Perhaps  the  most 
important  standard  is  the  Java  2  Enterprise  Edition  (J2EE).  Using  Commercial  off  the  shelf  (COTS) 
applications  (such  as  TIBCO  and  Web  Logic)  to  enhance  the  utilization  of  these  standards  increases  the 
stability  and  effectiveness  of  an  application  and  makes  the  VSLRC  an  operationally  responsive  system  to 
meet  customer  requirements. 

6.1.1  Web-Based 

With  the  emergence  of  the  World  Wide  Web,  virtually  everyone  in  the  civilized  world  is  now  aware  of 
the  power  of  the  Internet  in  delivering  a  vast  array  of  information  to  a  worldwide  community  of  users 
with  disparate  computer  and  communications  systems.  Explosive  growth  of  Air  Force  and  Joint  Systems 
using  electronic  commerce  over  the  Internet  are  becoming  the  “norm”. 

For  the  most  part,  building  Web  pages  today  is  largely  a  matter  of  using  Hyper  Text  Markup  Language 
(HTML).  HTML  is  suitable  for  allowing  users  to  find  and  read  documents  and  link  from  one  document 
to  another.  However,  developing  meaningful  and  robust  applications  for  the  Internet  requires  the  use  of 
other  languages  and  techniques. 

The  Web  can  be  leveraged  for  enterprise  computing  by  creation  of  a  web  portal. 
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6.1-2  Disparate  Databases 

There  are  many  data  sources  and  tools  used  by  personnel  throughout  Air  Force  Space  Command.  Many 
of  these  will  contribute  to  the  VSLRC.  Some  systems  contain  data  that  the  VSLRC  must  collect,  process, 
analyze  and  report,  while  others  contain  functionality  that  may  be  integrated  into  the  VSLRC.  Interface 
linkages  will  be  created  between  various  systems  and  the  VSLRC.  No  single  system  exists  today  that 
provides  all  of  the  capabilities  required  by  the  VSLRC  and  many  of  the  existing  systems  cannot  “talk”  to 
each  other.  Some  data  sources  may  use  Oracle  while  others  use  Access  or  other  tools  for  their  databases. 
Developing  a  standardized  source  for  all  the  needed  data  and  a  standardized  “Suite  of  Tools”  to  be  used 
will  vastly  increase  the  availability  and  accuracy  of  the  needed  information. 

6.1.3  Interoperable  Components  -  Message  Oriented  Middleware 

In  the  past,  the  dominant  method  for  integrating  functional  “stove-pipe”  systems  has  been  to  develop  a 
single  integrated  database.  Some  progress  has  been  made  in  merging  some  conglomerations  of  “stove¬ 
pipe”  systems  into  larger  systems,  but  the  complexity  of  the  integration  grows  exponentially  as  the  size  of 
the  integration  grows.  Generally,  large  integration  efforts  of  this  type  have  failed  due  to  underestimation 
of  the  complexity  of  the  required  database  and  the  amount  of  effort  required  to  recode  business  logic  to 
replace  legacy  systems.  More  recently  an  alternative  integration  concept  has  emerged  in  large 
commercial  enterprises.  This  strategy  is  focused  on  defining  the  business  transactions  required  across  the 
enterprise  and  using  MOM  t(^  ensure  appropriately  formatted  messages  are  broadcast  to  network  nodes  as 
business  events  occur.  The  best  MOM  supports  event  driven  “server  push”,  or  real-time  broadcast  of 
information  and  has  a  number  of  advanced  capabilities,  including  subject-based  addressing,  self¬ 
describing  data,  and  delivery  services  that  include  certified  messaging,  fault-tolerance,  and  distributed 
queues.  Since  MOM  uses  subject-based-addressing,  rather  than  conventional  point-to-point  sockets  and 
IP  addresses,  it  allows  the  designer  to  think  in  terms  of  a  “logical  architecture  of  connectivity,”  in  which 
the  MOM  acts  as  a  pipe  between  any  two  systems.  External/legacy  system  integration  is  accomplished  by 
encapsulating  events  in  messages  through  the  use  of  an  adapter.  The  events  can  be  “subscribed  to”  by 
each  downstream  stakeholder  in  the  process.  Adapters  exist  for  databases  such  as  Oracle,  so  it  is  possible 
to  enable  the  information  bus  with  these  events  quickly.  The  high  level  architecture  for  Legacy  Systems 
Integration  solutions  (Figure  6-1)  is  as  follows: 
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Figure  6-1.  Legacy  Integration  with  MOM 

This  diagram  (reference  Figure  6-1  Legacy  Integration  with  MOM)  shows  two  legacy  applications,  each 
of  which  have  a  adapter  which  creates  messages  on  the  bus.  In  the  middle  is  a  transformer  which  is  used 
to  convert  the  business  objects  which  appear  on  the  left-hand  adapter  over  to  the  business  object  expected 

on  the  right-hand  adapter.  The  adapters  and  the  transformer  use  information  located  in  the  repository  to 
the  right. 

MOM  techniques  have  yielded  some  astounding  successes  in  leveraging  investment  in  legacy  systems 
while  moving  enterprises  to  an  event-driven  model.  However,  this  technique  is  not  a  panacea.  Some 
distributed  components  in  complex  enterprises  require  tighter  coupling  than  can  be  accomplished  through 
messaging  and  can  best  be  achieved  using  a  distributed  component  model  as  described  above.  However, 
many  processes  can  be  quickly  and  significantly  improved  while  leveraging  legacy  systems  using  MOM. 
MOM  can  also  be  very  useful  for  transition  periods  while  migrating  away  from  legacy  systems.  MOM  is 
also  very  useful  for  interfacing  with  external  systems.  Regardless  of  the  size  of  an  integration  effort, 
interaction  with  external  systems  is  likely  to  be  required.  MOM  is  especially  well  suited  to  the 
integration  of  legacy  systems.  As  outsourcing  and  privatization  increases,  there  will  be  an  increasing 
need  for  event-driven  communication  between  the  Air  Force  Space  Command  systems  and  systems 
belonging  to  suppliers  of  key  services  and  materiel.  Commercial  examples  of  using  this  design  include 
linkage  of  Enterprise  Resource  Planning  (ERP)  systems  to  legacy  systems.  Furthermore,  the  Business-to- 
Business  (B2B)  paradigm  could  be  adapted  to  allow  the  flow  of  requirements  from  government  to 
business  and  the  flow  of  resource  information  back  to  Government,  completing  a  Govemment-to- 
Business-to-Government  (G2B2G)  cycle. 

There  are  competing  products  in  the  MOM  market.  The  best  produces  a  vast  array  of  useful  features  that 
leverage  the  messaging  layer  and  allow  message  management,  message-based  interaction  between  the 
components,  and  adapters  that  integrate  various  third-party  software  systems  and  transform  message 
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formats  so  they  can  be  used  by  disparate  systems,  integrate  with  web  portals,  enable  workflow 
management,  distributed  monitoring  plan,  some  MOM  vendors  provide  a  flexible  system  and  application 
monitoring  facility.  This  enables  applications  to  send  status  notifications,  and  monitoring  tools  to 
subscribe  to  such  messages  and  provide  monitoring  and  alerting. 

6.1.4  Role-Based  Control 

Considering  the  physical  separations  and  the  varying  responsibilities  of  the  personnel  throughout  Air 
Force  Space  Command  and  its  user  community,  developing  a  Role-Based  Control  system  will  be  very 
beneficial.  At  the  risk  of  over  simplification,  several  examples  of  potential  roles  would  include  the  SSMs 
and  their  staff,  who  would  need  access  to  the  data  required  to  give  them  the  overall  long-term  system 
health  picture;  NAF  Users,  who  require  access  to  data  and  tools  allowing  easy  creation  of  MICAP 
Reports  and  AOC  Briefings;  and  Wing  Level  Operators,  who  are  responsible  for  providing  real-time 
operational  status.  Creating  access  to  the  data  and  tools  directly  related  to  an  individual’s  role  eliminates 
their  need  to  extrapolate  the  needed  information  from  volumes  of  data  and  standardizes  the  data  source 
and  currency  for  everyone.  This  will  inherently  give  a  more  accurate  picture  of  current  system  status. 

6.1.5  Portal  Environment 

A  well-implemented  portal  is  essentially  a  web  site  that: 

•  Allows  easy  access  to  all  content  associated  with  an  enterprise 

•  Creates  a  sense  of  community  among  the  enterprise  stakeholders 

•  Allows  users  to  customize  their  interface  or  “home  page”  based  on  personal  preferences  and 
organizational  role 

•  Displays  real-time  information,  alerts,  and  “business  monitors” 

•  Controls  access  based  on  user  identification 

6.1.6  Notional  Infrastructure 

In  an  effort  to  begin  using  an  enterprise  component  approach  to  system  development  that  reuses  key 
components,  data  elements,  calculations,  etc.  from  various  other  systems  and  capitalizes  off  those 
investments  and  opportunities,  the  notional  infrastructure  as  described  in  Figure  6-2  is  suggested.  This 
infrastructure  would  provide  the  most  cohesive  workflow  management  enterprise  to  meet  the  various 
stakeholder  needs,  instead  of  a  stovepipe  or  independent  development  approach  that  subsequently 
requires  endless  interface  considerations. 


53 


Figure  6-2,  Notional  VSLRC  Technological  Infrastructure 

6.2  Standards 

•  AFI  10-602  Determining  Mission  Capability  and  Supportability  Requirements,  30  Sep  02 

•  Global  Command  Support  System  (GCSS)  Standards 

•  GRID-Centric  Enterprise  Services  Standards 

•  AFI  10-202 

6.3  Assumptions  and  Constraints 

With  any  system  integration  effort  there  exists  data  “gaps”  where  data  owned  and/or  provided  by 
contractor  or  other  services  is  difficult  to  obtain  or  integrate  within  the  foundation  of  an  existing  system. 
The  VSLRC  will  depend  on  key  data  elements  from  contractor  other  services  and  legacy  systems,  which 
may  require  contract  modifications  or  additional  communication  tiers  to  gather  the  necessary  data. 
Transition  between  classified  and  unclassified  environments  and  any  C2  guards  or  other  mechanisms  for 
providing  this  data  will  need  to  be  explored. 
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Access  to  Government-owned  data  sources  (e.g.,  CAMS,  EDW,  SBSS,  etc)  will  also  be  required. 
Therefore,  it  is  necessary  that  the  VSLRC  obtain  the  appropriate  access  to  such  data  in  real  time  status  in 
order  to  provide  the  user  with  the  most  accurate  and  updated  information  as  possible. 

Business  rules  must  be  established  for  the  identification  of  Operations  Capability  (OPSCAP),  Systems 
Capability  (SYSCAP),  FMC,  PMC,  and  NMC  in  order  for  the  VSLRC  to  calculate  and  identify  the 
appropriate  status  to  the  various  echelons  of  the  AFSPC. 

7  Conclusion  and  Recommendation 

It  is  apparent  from  the  requirements  research  and  analysis  that  a  VSLRC  will  help  the  entire  AF  Space 
community  employ,  manage  and  sustain  Space  assets  more  efficiently  and  effectively.  If  implemented, 
the  VSLRC  will: 

•  Align  the  AF  Space  Community’s  understanding  of  the  real-time  status  and  long-term  health  of 
Space  systems  worldwide 

•  Eliminate  duplication  in  analysis,  data  entry  and  reporting 

•  Alert  members  of  the  supply  chain  -  all  the  way  to  the  system  user  -  of  logistics  problems  that 
may  impact  operations 

•  Streamline  logistics  support  and  sustainment  by  integrating  information  from  disparate 
information  systems  and  alerting  key  individuals  to  disconnects  within  the  logistics  system 

Conduct  further  requirements  research  and  analysis  to  validate  functional  requirements  and  based  on  this 
assessment,  recommendations  for  further  action  regarding  the  development  of  a  VSLRC  are: 

•  Obtain  senior-level  buy  in  from  HQ  AFSPC,  Det  1 1 ,  SMC,  Det  5, 14"’  AF,  and  OO-ALC/LH  for 
the  VSLRC  concept 

•  Finalize  and  present  the  VSLRC  Conceptual  Demonstration  based  on  known  system  requirements 
outside  of  the  Navigation  Satellite  Timing  and  Ranging  (NAVSTAR)  GPS  community 

•  Integrate  functionality  from  existing,  useful  software  tools  and  systems  where  cost  effective  and 
feasible  (e.g.,  LOCIS,  50"’  Maintenance  Group  Web  Site,  ORA,  etc.) 

•  Conduct  a  detailed  review  of  LOCIS  to  determine  which  components  may  be  modified  and  re¬ 
used  in  the  VSLRC 

•  Further  define  the  VSLRC  architecture  based  on  validated  requirements  and  the  LOCIS  review 
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•  Develop  a  migration  strategy  that  will  transition  the  VSLRC  from  the  concept  stage,  to  the 
development  phase,  and  through  to  deployment  and  sustainment 

•  Identify  specific  data  elements  and  sources,  which  will  populate  function  points  and  lead  towards 
a  phased  development  of  a  VSLRC 

8  Acronym  List 


ADPE 

Automated  Data  Processing  Equipment 

AOC 

Aerospace  Operations  Center 

ATE 

Automated  Test  Equipment 

AF 

Air  Force 

AFMC 

Air  Force  Material  Command 

AFSCN 

Air  Force  Satellite  Control  Network 

AFSPC 

Air  Force  Space  Command 

AFRL 

Air  Force  Research  Lab 

AWP 

Awaiting  Parts 

B2B 

Business-to-Business 

BCS 

Balanced  Scorecard 

C2 

Command  and  Control 

CAGE 

Commercial  and  Government  Entity 

CAMS 

Core  Automated  Maintenance  System 

CBRN 

Chemical,  Biological,  Radiological,  and  Nuclear 

CISF 

Centralized  Integration  Support  Facility 

CONOPs 

Concept  of  Operations 

COTS 

Commercial  off  the  shelf 

CSO 

Chief  Sustainment  Officer 

CWT 

Customer  Wait  Time 

DAC 

Defense  Acquisition  Circular 

Det 

Detachment 

DISA 

Defense  Information  Systems  Agency 

DLA 

Defense  Logistic  Agency 

DoD 

Department  of  Defense 

DSP 

Defense  Support  Program 

DSS 

Decision  Support  System 

DSCS 

Deep  Space  Tracking  System 

EDD 

Estimated  delivery  Date 

EDW 

Enterprise  Data  Warehouse 

ESC 

Electronic  System  Center 

ESR 

Equipment  Status  report 

ERRC 

Expendability,  Recoverability,  Reparability  Code 
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FMC 

Fully  Mission  Capable 

FTP 

File  Transfer  Protocol 

FY 

Fiscal  Year 

G2B2G 

Government-to-Business-to-Govemment 

GIDEP 

Govemment/Industry  Data  Exchange  Program 

GPS 

Global  Positioning  Satellite 

HQ 

Headquarters 

HTML 

Hyper  Text  Markup  Language 

I&SG 

Interchangeable  and  Substitution  Group 

ICBM 

Intercontinental  Ballistic  Missiles 

IMDS 

Integrated  Maintenance  Data  System 

JCS 

Joint  Chief  of  Staff 

JNDI 

Java  and  Naming  Directory  Interface 

JSP 

Java  Server  Page 

LASAR 

Logistics  Analysis  Supportability  Assessment  Resource 

LMS 

Log  Mgt  Spec 

LRT-AF 

Logistics  Response  Time-Air  Force 

MCRS 

Mission  Critical  Reporting  System 

MOD 

Maintenance  Data  Documentation 

MERLIN 

Multi-Echelon  Resource  and  Logistics  Information  Network 

MGS 

Mars  Global  Surveyor 

MICAP 

Mission  Impaired  Capability  Awaiting  Parts 

MILSATCOM 

Military  Satellite  Communications 

MOM 

Message  Oriented  Middleware 

MPP 

Modernization  Planning  Process 

NAF 

Numbered  Air  Force 

NATO 

North  Atlantic  Treaty  Organization 

NAVSTAR 

Navigation  Satellite  Timing  and  Ranging 

NMC 

Non-Mission  capable 

NORAD 

North  American  Aerospace  Defense  Command 

NSN 

National  Stock  Numbers 

ocs 

Operator  Control  Station 

OO-ALC 

Ogden-Air  Logistics  Center 

ORA 

Operational  Readiness  Analysis  system 

OPSCAP 

Operations  Capability 

PDM 

Programmed  Depot  Maintenance 

PEO 

Program  Executive  Officer 

PIN 

Parts  Information  Network 

PMC 

Partial  Mission  Capable 

POM 

Program  Objective  Memorandum 

PPAS 

Pipeline  Performance  Analysis  System 
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PSA 

Predictive  Support  Awareness 

RAMES 

Reliability,  Availability  and  Maintainability  Engineering  System 

RDB 

Requirements  Data  Bank 

RDD 

Required  Delivery  Date 

REALM 

Requirements/Execution  Availability  Logistics  Module 

REMIS 

Reliability  and  Maintainability  Information  System 

ROI 

Return  on  Investment 

SAE 

Service  Acquisition  Executive 

SBLC 

Standard  Base-Level  Computer 

SBMCS 

Space  Battle  Management  Core  System 

SBSS 

Standard  Base  Supply  System 

SEMR 

System  Executive  Management  Report 

SENSORNET 

Sensor  Network 

SIPRNET 

Secure  Internet  Protocol  Network 

SFTREPS 

Situation  Report 

SMART 

Systems  Metric  and  Reporting  Tool 

SMC 

Space  and  Missile  System  Center 

SOR 

Source  of  Repair 

SORAP 

Source  of  Repair  Assignment  Process 

SOS 

Source  of  Supply 

SSM 

System  Support  Manager 

SPD 

System  Program  Directors 

SPF 

Single  Point  Failure  item 

SYSCAP 

Systems  Capability 

UDRI 

University  of  Dayton  Research  Institute 

USSPACECOM 

United  States  Space  Command 

USSTRATCOM 

United  States  Strategic  Command 

\/y 

Vanishing  Vendor 

YARD 

Variance  Analysis  Reporting 

VICP 

Virtual  Networking  System  (VINES)  Internet  Control  Protocol 

VSLRC 

Virtual  Space  Logistics  Readiness  Center 

WARRS 

Wholesale  and  Retail  Receiving  and  Shipping 

WICAP 

Worldwide  Industrial  Capabilities  Assessment  Program 

WRM 

War  readiness  Material 

WSAP 

Weapon  System  Analysis  Program 

WSMIS 

Weapons  System  Management  Information  Systems 

WSSP 

Weapon  System  Support  Program 
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Appendix  A 
Metrics  Matrix 
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Svttenw 

Metrics  SLRS  GPS  AFSCN  AF  Ground  Sys  Spt  Sat  Ops 

Operational  Avaiability  (Ao)  MTBDE/MTBDE-»-MDT  MTBDE/MTBDE-»-MTTRS  MTBDE/MTBDE-«-MDT  MTBDE/MTBDE+MDT 

Total  Hours  of  Satellite 
Uptime/Totai  Hours 


other  MICAPs  I  All  Other  MICAPS;  Total 

Number  Per  12  mo  (x) 
Green  if;  x  <=  54  Yellow 
if:  54  <  X  <=  57  Red  if:  x 
>57 
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X  =  Avg  Repair  Time:  y  = 
MICAps/NSN:  Red  x 
>120  and  v  >3 


Total  Successful 
Missions/Number  of  Missions 


Total  UDLMs/Reporting  Period 


Unscheduled  Depot  Level  Maintenance;  Nodes 
System  Perfomiance 


